Błąd 500 Internal Server Error — to jeden z najczęstszych problemów, z którymi mogą się spotkać właściciele i administratorzy stron internetowych. Oznacza, że na serwerze wystąpił błąd, ale komunikat nie precyzuje jego przyczyny. W tym artykule wyjaśniamy, co może powodować błąd 500 oraz jak skutecznie go rozwiązać.

Możliwe przyczyny błędu 500​

Błąd 500 może pojawiać się z różnych powodów. Oto najczęstsze z nich:

1. Problemy z serwerem

Często błąd 500 jest efektem technicznych problemów na serwerze, takich jak niedobór zasobów (RAM, CPU).

2. Błędy w kodzie strony

Skrypty lub kod witryny mogą zawierać błędy, które powodują awarię strony. Może to być spowodowane nieprawidłowymi żądaniami, błędami w plikach konfiguracyjnych lub problemami z interakcją komponentów strony.

3. Problemy z plikiem .htaccess

Plik .htaccess służy do konfiguracji serwera WWW i może zawierać błędy, które spowodują błąd 500. Na przykład nieprawidłowe reguły przekierowania lub nieprawidłowe parametry mogą spowodować niepowodzenie.

4.  Ostatnie aktualizacje

Błędy mogą pojawić się po aktualizacjach CMS-a, wtyczek lub komponentów serwera, jeśli nie zostały one prawidłowo przetworzone.

Jak naprawić błąd 500​

1. Sprawdź logi serwera WWW

Pierwszym krokiem powinna być analiza logów serwera. To właśnie tam znajdziesz przyczynę błędu — czy to w kodzie, konfiguracji czy na poziomie serwera. Ważne: logi serwera WWW (np. Nginx lub Apache) często zawierają tylko sam kod błędu, bez dokładnych szczegółów — szczególnie w przypadku Nginx, który często działa jako proxy i jedynie przekazuje błąd z backendu.

W zależności od używanego serwera WWW dzienniki mogą znajdować się w następujących lokalizacjach:

Apache:

• Ubuntu/Debian: /var/log/apache2/error.log

• CentOS/AlmaLinux/Rocky Linux: /var/log/httpd/error.log

Nginx:

• /var/log/nginx/error.log

Jeśli serwer jest zarządzany za pomocą panelu sterowania, takiego jak FASTPANEL, przeglądanie dzienników staje się jeszcze łatwiejsze. Aby to zrobić, należy:

• Przejść do panelu sterowania.

• Otworzyć kartę strony, zakładka „Logi”. 

• W zakładce „Dziennik błędów frontend” znajdziesz logi Nginx, a w „Dzienniku błędów backend” — logi Apache.

Dodatkowo, wiele CMS-ów i frameworków (WordPress, Joomla, Laravel itd.) prowadzi własne dzienniki błędów. Te dzienniki często zawierają bardziej precyzyjne informacje na temat przyczyny błędu 500. Zaleca się zapoznanie się z dokumentacją systemu w celu znalezienia lokalizacji tych dzienników.

Dzienniki najprawdopodobniej dostarczą szczegółowych informacji o tym, co dokładnie poszło nie tak. Jeśli błąd 500 jest spowodowany błędną konfiguracją lub błędami kodu, będziesz w stanie zobaczyć pliki lub określone linie w nich, które powodują awarię.

2. Włączenie logowania błędów po stronie PHP

Aby uzyskać szczegółowe informacje o błędach po stronie kodu, warto włączyć logowanie w samym PHP. Jest to szczególnie przydatne, jeśli błąd występuje na poziomie kodu i nie pojawia się w logach serwera WWW.

W tym celu należy ustawić następujące wartości w pliku php.ini:

display_errors = Off

log_errors = On

error_log = /var/log/php_errors.log

Gdzie:

• display_errors — wyłącza wyświetlanie błędów w przeglądarce

• log_errors — włącza zapisywanie błędów do logu

• error_log — ścieżka do pliku logu (PHP musi mieć uprawnienia do zapisu w tym katalogu)

Plik php.ini zazwyczaj znajduje się w lokalizacji:

• Debian/Ubuntu: /etc/php/*/apache2/php.ini lub /etc/php/*/cli/php.ini

• CentOS/AlmaLinux: /etc/php.ini

Można też użyć polecenia:

php -i | grep "php.ini"

W FASTPANEL wystarczy przejść do karty strony → sekcja „Ustawienia PHP”, wyszukać powyższe zmienne (np. display_errors), zmienić ich wartość i kliknąć „Zapisz”.  

3. Sprawdź plik .htaccess.

Jeśli błąd pojawił się po modyfikacji .htaccess, przywróć jego poprzednią wersję.

Jeśli nie masz pewności, co zostało zmienione — tymczasowo zmień nazwę pliku .htaccess (np. na .htaccess.bak). Jeśli błąd zniknie, oznacza to, że problem tkwił w tym pliku.

W takim przypadku spróbuj przywrócić plik .htaccess z kopii zapasowej, o ile jest dostępna, lub użyj domyślnego pliku .htaccess dla swojego systemu CMS, który możesz pobrać tutaj.

4. Sprawdź uprawnienia i właściciela plików 

Błąd może być spowodowany nieprawidłowymi uprawnieniami plików lub katalogów. Upewnij się, że katalog główny strony oraz wszystkie podkatalogi i pliki mają poprawne prawa i właściciela.

ls -laR /ścieżka/do/katalogu/strony

Zalecane uprawnienia:

• Dla katalogów: 755 (odczyt, zapis i wykonanie dla właściciela; odczyt i wykonanie dla innych).

• Dla plików: 644 (odczyt i zapis dla właściciela; odczyt dla innych).

Właściciel:

Pliki i katalogi powinny należeć do użytkownika, pod którym działa serwer WWW (np. www-data lub apache).

Aby zmienić właściciela i uprawnienia, użyj następujących poleceń:

• Przejdź do katalogu swojej witryny:

cd /ścieżka/do/katalogu/strony

• Zmień prawa i właściciela na prawidłowe:

sudo chown -R yoursiteuser:yoursiteuser . && sudo chmod 644 . -R && sudo chmod +X . -R

Zamień yoursiteuser na rzeczywistego użytkownika i grupę, do której należy Twoja strona. 

5. Wyłącz wtyczki i motywy.

W przypadku CMS-ów (np. WordPress), błąd 500 często wynika z konfliktów między wtyczkami lub motywami. Wyłącz wszystkie wtyczki i przełącz motyw na domyślny, aby sprawdzić, czy to rozwiązuje problem.

6. Upewnij się, że serwer ma wystarczającą ilość wolnych zasobów do uruchomienia danych stron 

• Sprawdź, czy serwer ma wystarczającą ilość wolnego miejsca na dysku:

sudo df -h

• Sprawdź, czy nie zabrakło inode’ów:

sudo df -ih

• Sprawdź dostępność pamięci operacyjnej:

sudo free -mh

• Sprawdź obciążenie procesora:

sudo ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head

• Lub uruchom monitor procesów z pomocą komendy:

sudo top

Jeśli brakuje miejsca na dysku lub inode’ów, możesz sprawdzić, które pliki i katalogi zajmują najwięcej miejsca — skorzystaj z instrukcji zawartej w dedykowanym artykule.

Jeśli obciążenie pamięci operacyjnej i procesora jest zbyt wysokie, przyczyn może być wiele. Spróbuj rozpocząć analizę tego problemu od zablokowania botów wyszukiwania, ponieważ to one często są źródłem zwiększonego obciążenia. 

7. Upewnij się, że wszystko w porządku z bazą danych.

Najczęściej używaną bazą danych jest MySQL, dlatego poniżej kilka prostych kroków, które pozwolą sprawdzić jej stan: 

• Sprawdź, czy usługa MySQL działa:

sudo systemctl status mysql

• Sprawdź log błędów MySQL:

sudo grep -i error /var/log/mysql/error.log

• Przeprowadź sprawdzenie baz danych pod kątem błędów:

mysqlcheck -A -c

Jeśli zostaną wykryte błędy, upewnij się, że posiadasz kopie zapasowe baz danych, których dotyczą problemy. Jeśli ich nie masz, możesz je utworzyć za pomocą polecenia:

mysqldump -u [użytkownik] -p [nazwa_bazy_danych] > /ścieżka/do/pliku/dump.sql

• Zamień [użytkownik] na nazwę użytkownika MySQL.

• Zamień [nazwa_bazy_danych] na nazwę bazy danych, którą chcesz wyeksportować.

• /ścieżka/do/pliku/dump.sql — na ścieżkę, gdzie ma zostać zapisany zrzut.

Następnie należy uruchomić procedurę korekcji błędów za pomocą mysqlcheck:

mysqlcheck -A --auto-repair -c

8. Skontaktuj się z dostawcą hostingu.

Jeśli nie udało Ci się zidentyfikować przyczyny problemu samodzielnie, warto skontaktować się z pomocą techniczną Twojego dostawcy hostingu. Może to pomóc zidentyfikować problemy na serwerze, które nie są widoczne na poziomie użytkownika. Jak wybrać odpowiedniego dostawcę hostingu dowiesz się z tego artykułu.

Podsumowanie​

Błąd 500 to nie wyrok dla Twojej strony. Dzięki podstawowym narzędziom diagnostycznym możesz szybko zlokalizować i naprawić przyczynę problemu. Jeśli nie czujesz się na siłach — zawsze możesz zwrócić się o pomoc do specjalistów. Pamiętaj: szybko wykryty i usunięty błąd 500 pozwala uniknąć poważniejszych problemów w przyszłości.

Błąd 404 Not Found w witrynie opartej na CMS Joomla oznacza, że serwer nie może odnaleźć żądanej strony. Użytkownicy mogą natrafić na ten komunikat, klikając linki z wyszukiwarki, starych odnośników, a nawet z menu wewnętrznego witryny. Przyczyny występowania tego błędu są różne — od prostego usunięcia treści, przez błędy w strukturze menu, aż po problemy z komponentami odpowiedzialnymi za wyświetlanie strony.

W tym artykule wyjaśnimy, dlaczego pojawia się błąd 404 w Joomla i jak możesz go szybko naprawić.

Co oznacza błąd 404 w Joomla​

Błąd 404 to standardowa odpowiedź HTTP, która informuje, że serwer nie znalazł strony odpowiadającej podanemu adresowi URL. W Joomla najczęstsze przyczyny to:

• Usunięta lub zdezaktywowana treść;

• Uszkodzona struktura menu;

• Nieprawidłowe działanie komponentu odpowiedzialnego za generowanie treści.

Główne przyczyny błędu 404 w Joomla​

1. Usunięta lub wyłączona treść

Jeśli usuniesz artykuł, kategorię lub komponent, ale w menu lub module nadal istnieje do nich odnośnik — Joomla wyświetli błąd 404.

2. Pozycja menu wskazuje na nieistniejący artykuł

Błąd może się pojawić, gdy pozycja menu wskazuje na artykuł, który został przeniesiony, przypisany do nieistniejącej kategorii lub ma błędnie ustawioną trasę — nawet jeśli sam artykuł fizycznie istnieje.

3. Problemy z SEF (przyjaznymi adresami URL)

Joomla generuje tzw. SEF URL-e, zależne od tras komponentów. Po migracji, włączeniu opcji SEO lub zmianie aliasów, mogą pojawić się niedziałające linki prowadzące do stron, które nie istnieją.

4. Błędy po migracji witryny

Przeniesienie strony na inny serwer lub domenę może spowodować zmianę struktury adresów URL. Jeśli nie zostaną odpowiednio dostosowane, część stron może stać się niedostępna.

5. Brak wymaganego komponentu

Jeśli adres URL wskazuje np. na index.php?option=com_k2&view=item&id=1, ale komponent K2 nie jest zainstalowany lub został usunięty — Joomla nie będzie w stanie zidentyfikować ścieżki i wyświetli błąd 404.

Jak naprawić 404 w Joomla​

1. Sprawdź pozycje menu

Przejdź do Menu → Menu główne i upewnij się, że każda pozycja prowadzi do istniejącego artykułu, kategorii lub komponentu. Jeśli to konieczne, odtwórz pozycję menu.

2. Zregeneruj linki SEF

• W panelu administracyjnym przejdź do: Konfiguracja → Witryna → Ustawienia SEO.

• Upewnij się, że opcje przyjazne adresy URL (SEF) oraz przepisywanie URL są włączone.

• Wyczyść pamięć podręczną Joomla: System → Wyczyść pamięć podręczną.

• Jeśli używasz komponentu takiego jak sh404SEF lub JoomSEF - zaktualizuj tabelę SEF lub zresetuj ją.

3. Sprawdź .htaccess

Dla prawidłowego działania SEF musisz mieć aktywne przepisywanie adresów URL. Upewnij się, że masz .htaccess w katalogu głównym witryny i masz włączony mod_rewrite:

RewriteEngine On

RewriteBase /

Aby uzyskać więcej informacji na temat domyślnej struktury .htaccess w Joomla, zapoznaj się z tym artykułem.

4. Włącz wyświetlanie błędów

Aby uzyskać więcej informacji, włącz wyświetlanie błędów:

• Przejdź do System → Ustawienia ogólne → Serwer.

• Ustaw opcję Komunikaty o błędach na Maksymalnie.

Joomla wyświetli wtedy bardziej szczegółowy komunikat, aby pomóc Ci znaleźć przyczynę błędu.

5. Sprawdź dzienniki błędów

Dziennik błędów Apache jest dostępny na większości hostów internetowych. Poszukaj wierszy z kodem 404 — możesz ich użyć, aby dowiedzieć się, które adresy URL powodują problem.

Jeśli korzystasz z FASTPANEL, wejdź w kartę strony → zakładka „Logi” → sprawdź „Dziennik dostępu backend” i „Dziennik dostępu frontend”. Dzięki temu dowiesz się, które adresy wywołują błędy 404 i skąd pochodzą żądania — pomoże to zlokalizować uszkodzone linki.

6. Ustaw przekierowania

Jeśli jakaś strona została usunięta, ale chcesz zachować ruch z zewnętrznych linków, ustaw przekierowanie. W Joomla odbywa się to za pomocą komponentu „Redirects” (Przekierowania):

• Przejdź do Komponenty → Przekierowania.

• Włącz komponent, jeśli jest nieaktywny.

• Dodaj stary adres URL oraz nową ścieżkę (bez domeny).

Jak zapobiec błędom 404 w przyszłości​

• Nie usuwaj treści bez ustawienia przekierowania.

• Po przeniesieniu lub wyłączeniu treści sprawdzaj powiązane pozycje menu.

• Używaj komponentu Redirects lub pliku .htaccess do zarządzania przekierowaniami.

• Regularnie sprawdzaj błędy 404 w Google Search Console.

Podsumowanie​

Błąd 404 w Joomla to powszechny problem, który zazwyczaj można szybko naprawić. W większości przypadków jego usunięcie zajmuje zaledwie 5–10 minut — wystarczy sprawdzić pozycje menu, konfigurację SEF oraz strukturę strony. Aby uniknąć utraty ruchu z usuniętych stron, warto wdrożyć system przekierowań, który skutecznie minimalizuje ryzyko błędów 404.

Błąd 404 Not Found — jeden z najczęstszych problemów, z jakimi mierzą się właściciele stron opartych na WordPressie. Komunikat pojawia się, gdy serwer nie może znaleźć strony żądanej przez użytkownika. Przyczyną może być nieprawidłowe ustawienie linków, usunięta treść lub nawet problem z szablonem strony.

Jeśli błąd nie zostanie rozwiązany, może negatywnie wpłynąć na doświadczenie użytkownika oraz pozycję strony w wynikach wyszukiwania. W tym artykule znajdziesz konkretne informacje na temat tego, skąd bierze się błąd 404 w WordPressie i jak skutecznie się go pozbyć.

Co oznacza błąd 404 w WordPress​

Gdy ktoś odwiedza Twoją stronę, WordPress próbuje dopasować adres URL do wpisów w bazie danych. Jeśli nie znajdzie strony — pojawia się komunikat 404. To nie jest awaria serwera — strona działa, ale konkretny adres jest nieprawidłowy lub nie istnieje.

Dlaczego błąd 404 pojawia się w WordPress​

1. Nieprawidłowa struktura bezpośrednich odnośników

To jedna z najczęstszych przyczyn. Przykład: zmieniono strukturę linków w „Ustawienia” → „Bezpośrednie odnośniki”, ale WordPress nie zaktualizował pliku .htaccess. W efekcie wszystkie podstrony, poza główną, mogą zwracać błąd 404. Jak to naprawić: Ręcznie zaktualizuj plik .htaccess lub po prostu kliknij „Zapisz zmiany” w ustawieniach bezpośrednich odnośników – to wymusi regenerację pliku .htaccess.

2. Strona lub wpis został usunięty

Jeśli usunięto stronę/wpis, ale odnośniki do niej nadal istnieją (np. w menu, wynikach wyszukiwania lub na innych stronach), użytkownicy będą trafiać na 404.

3. Uszkodzony lub usunięty plik .htaccess

Ten plik odpowiada za przetwarzanie adresów URL. Jeśli został usunięty lub uszkodzony, WordPress nie poradzi sobie z adresacją.

4. Problemy z motywem lub wtyczkami

Błąd może pojawić się po instalacji/aktualizacji wtyczki (zwłaszcza obsługującej URL-e, niestandardowe typy wpisów itp.) lub przez błędy w pliku functions.php motywu.

Jak naprawić błąd 404 w WordPress​

✅ 1. Odśwież ustawienia bezpośrednich odnośników

Przejdź do Panelu administracyjnego → Ustawienia → Bezpośrednie odnośniki → i kliknij „Zapisz zmiany” — nawet jeśli nic nie zmieniasz. To zaktualizuje strukturę i plik .htaccess.

✅ 2. Sprawdź plik .htaccess

Połącz się z serwerem przez FTP lub menedżer plików w panelu hostingowym. Plik .htaccess znajduje się w katalogu głównym WordPressa. Domyślna zawartość wygląda tak:

# BEGIN WordPress

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</IfModule>

# END WordPress

Jeśli plik nie istnieje — utwórz go ręcznie z powyższą treścią. Upewnij się, że ma uprawnienia 644. Aby uzyskać więcej informacji na temat domyślnej struktury .htaccess w WordPress, zapoznaj się z tym artykułem.

✅ 3. Wyłącz podejrzane wtyczki

Jeśli błąd pojawił się po instalacji wtyczki — tymczasowo ją dezaktywuj. Jeśli używasz niestandardowych typów wpisów (np. produkty WooCommerce), sprawdź, czy wtyczka poprawnie rejestruje ścieżki.

✅ 4. Przełącz się na domyślny motyw

Czasem przyczyną błędu są błędy w szablonie. Włącz domyślny motyw WordPressa (np. Twenty Twenty-Four) i sprawdź, czy problem zniknął.

✅ 5. Włącz logowanie błędów

Dla celów debugowania można włączyć wyświetlanie błędów w WordPressie. W pliku wp-config.php dodaj linie:

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_LOG', true );

Po tym błędy będą zapisywane w pliku /wp-content/debug.log.

✅ 6. Sprawdź logi serwera

Jeśli korzystasz z FASTPANEL, wejdź w kartę strony → zakładka „Logi” → sprawdź „Dziennik dostępu backend” i „Dziennik dostępu frontend”. Dzięki temu dowiesz się, które adresy wywołują błędy 404 i skąd pochodzą żądania — pomoże to zlokalizować uszkodzone linki.

Jak uniknąć błędu 404 w przyszłości​

• Nie zmieniaj struktury linków bez wyraźnej potrzeby.

• Skorzystaj z wtyczki Redirection, aby skonfigurować przekierowania 301.

• Po usunięciu stron pamiętaj o aktualizacji menu i linków.

• Regularnie sprawdzaj błędy 404 w Google Search Console.

Podsumowanie​

Błąd 404 w WordPressie może być frustrujący, ale łatwy do rozwiązania. Najczęściej wystarczy ponowne zapisanie struktury linków lub edycja pliku .htaccess. Jeśli problem jest bardziej złożony, warto przejrzeć dziennik serwera lub plik debugowania.

Naprawiając błędy 404, poprawisz nie tylko komfort użytkowników, ale także pozycję swojej strony w wynikach wyszukiwania.

Plik .htaccess to plik konfiguracyjny używany na serwerach WWW Apache do zarządzania ustawieniami strony bez konieczności dostępu do głównego pliku konfiguracyjnego serwera. Może być używany do włączania przekierowań, ograniczania dostępu, konfigurowania przyjaznych adresów URL, buforowania i nie tylko - bezpośrednio z katalogu głównego strony lub dowolnego z jej katalogów.

Wiele systemów CMS tworzy ten plik automatycznie po instalacji lub oferuje przykład w dystrybucji.

Jeśli pracujesz z hostingiem, zwłaszcza opartym na Apache, warto wiedzieć, jak wygląda domyślny plik .htaccess dla różnych CMS. To może pomóc:

• Sprawdzić, czy wszystko działa poprawnie po instalacji;

• Przywrócić plik, jeśli został przypadkowo usunięty;

• Zrozumieć, jakie reguły system stosuje „prosto z pudełka”.

Gdzie znajduje się plik .htaccess​

Plik .htaccess zazwyczaj znajduje się w katalogu głównym strony, na przykład:

/var/www/site.com/public_html/.htaccess

Jeśli plik nie istnieje (np. został przypadkowo usunięty), można go utworzyć ręcznie z nazwą .htaccess (nazwa musi zaczynać się od kropki, bez rozszerzenia).

Otwórz plik w edytorze tekstu (np. Notepad++ lub VS Code). 

Poniżej znajduje się zestawienie standardowych plików .htaccess, które są domyślnie używane w popularnych CMS. Przykłady te mogą się przydać, jeśli przypadkowo usunąłeś lub uszkodziłeś oryginalny plik .htaccess i potrzebujesz go przywrócić, aby strona działała poprawnie.

Wordpress​

Domyślny .htaccess dla WordPress umożliwia działanie czystych adresów URL i zawiera podstawowe reguły przekierowań:

# BEGIN WordPress

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</IfModule>

# END WordPress

Jeśli używasz multisite z subdomenami (np. site1.example.com, site2.example.com):

# BEGIN WordPress Multisite

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

  

# Redirect for multisite (subdomains)

RewriteCond %{REQUEST_FILENAME} -f [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^ - [L]

RewriteRule ^(wp-(content|admin|includes).*) $1 [L]

RewriteRule ^(.*\.php)$ $1 [L]

RewriteRule . index.php [L]

</IfModule>

# END WordPress Multisite

Jeśli używasz multisite z podkatalogami (na przykład example.com/site1, example.com/site2):

# BEGIN WordPress Multisite

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

  

# Redirect for multisite (subdirectories)

RewriteCond %{REQUEST_FILENAME} -f [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^ - [L]

RewriteRule . index.php [L]

</IfModule>

# END WordPress Multisite

Joomla 2.5-3​

Joomla używa .htaccess do podstawowych zabezpieczeń i konfiguracji przyjaznych adresów:

##

# @package Joomla

# @copyright Copyright (C) 2005 - 2012 Open Source Matters. All rights reserved.

# @license GNU General Public License version 2 or later; see LICENSE.txt

##

  

##

# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!

#

# The line just below this section: 'Options +FollowSymLinks' may cause problems

# with some server configurations. It is required for use of mod_rewrite, but may already

# be set by your server administrator in a way that dissallows changing it in

# your .htaccess file. If using it causes your server to error out, comment it out (add # to

# beginning of line), reload your site in your browser and test your sef url's. If they work,

# it has been set by your server administrator and you do not need it set here.

##

  

## Can be commented out if causes errors, see notes above.

Options +FollowSymLinks

  

## Mod_rewrite in use.

  

RewriteEngine On

  

## Begin - Rewrite rules to block out some common exploits.

# If you experience problems on your site block out the operations listed below

# This attempts to block the most common type of exploit `attempts` to Joomla!

#

# Block out any script trying to base64_encode data within the URL.

RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]

# Block out any script that includes a <script> tag in URL.

RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]

# Block out any script trying to set a PHP GLOBALS variable via URL.

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

# Block out any script trying to modify a _REQUEST variable via URL.

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

# Return 403 Forbidden header and show the content of the root homepage

RewriteRule .* index.php [F]

#

## End - Rewrite rules to block out some common exploits.

  

## Begin - Custom redirects

#

# If you need to redirect some pages, or set a canonical non-www to

# www redirect (or vice versa), place that code here. Ensure those

# redirects use the correct RewriteRule syntax and the [R=301,L] flags.

#

## End - Custom redirects

  

##

# Uncomment following line if your webserver's URL

# is not directly related to physical file paths.

# Update Your Joomla! Directory (just / for root).

##

  

# RewriteBase /

  

## Begin - Joomla! core SEF Section.

#

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

#

# If the requested path and file is not /index.php and the request

# has not already been internally rewritten to the index.php script

RewriteCond %{REQUEST_URI} !^/index\.php

# and the request is for something within the component folder,

# or for the site root, or for an extensionless URL, or the

# requested URL ends with one of the listed extensions

RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw))$ [NC]

# and the requested path and file doesn't directly match a physical file

RewriteCond %{REQUEST_FILENAME} !-f

# and the requested path and file doesn't directly match a physical folder

RewriteCond %{REQUEST_FILENAME} !-d

# internally rewrite the request to the index.php script

RewriteRule .* index.php [L]

#

## End - Joomla! core SEF Section.

Joomla 4-5​

W pliku .htaccess Joomli 4 poświęcono więcej uwagi bezpieczeństwu i pamięci podręcznej:

##

# @package    Joomla

# @copyright  (C) 2005 Open Source Matters, Inc. <https://www.joomla.org>

# @license    GNU General Public License version 2 or later; see LICENSE.txt

##

  

##

# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!

#

# The line 'Options +FollowSymLinks' may cause problems with some server configurations.

# It is required for the use of Apache mod_rewrite, but it may have already been set by

# your server administrator in a way that disallows changing it in this .htaccess file.

# If using it causes your site to produce an error, comment it out (add # to the

# beginning of the line), reload your site in your browser and test your sef urls. If

# they work, then it has been set by your server administrator and you do not need to

# set it here.

##

  

## MISSING CSS OR JAVASCRIPT ERRORS

#

# If your site looks strange after enabling this file, then your server is probably already

# gzipping css and js files and you should comment out the GZIP section of this file.

##

  

## OPENLITESPEED

#

# If you are using an OpenLiteSpeed web server then any changes made to this file will

# not take effect until you have restarted the web server.

##

  

## Can be commented out if causes errors, see notes above.

Options +FollowSymlinks

Options -Indexes

  

## No directory listings

<IfModule mod_autoindex.c>

IndexIgnore *

</IfModule>

  

## Suppress mime type detection in browsers for unknown types

<IfModule mod_headers.c>

Header always set X-Content-Type-Options "nosniff"

</IfModule>

  

## Protect against certain cross-origin requests. More information can be found here:

## https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)

## https://web.dev/why-coop-coep/

#<IfModule mod_headers.c>

# Header always set Cross-Origin-Resource-Policy "same-origin"

# Header always set Cross-Origin-Embedder-Policy "require-corp"

#</IfModule>

  

## Disable inline JavaScript when directly opening SVG files or embedding them with the object-tag

<FilesMatch "\.svg$">

  <IfModule mod_headers.c>

    Header always set Content-Security-Policy "script-src 'none'"

  </IfModule>

</FilesMatch>

  

## These directives are only enabled if the Apache mod_rewrite module is enabled

<IfModule mod_rewrite.c>

RewriteEngine On

  

## Begin - Rewrite rules to block out some common exploits.

# If you experience problems on your site then comment out the operations listed

# below by adding a # to the beginning of the line.

# This attempts to block the most common type of exploit `attempts` on Joomla!

#

# Block any script trying to base64_encode data within the URL.

RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]

# Block any script that includes a <script> tag in URL.

RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]

# Block any script trying to set a PHP GLOBALS variable via URL.

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

# Block any script trying to modify a _REQUEST variable via URL.

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

# Return 403 Forbidden header and show the content of the root home page

RewriteRule .* index.php [F]

#

## End - Rewrite rules to block out some common exploits.

  

## Begin - Custom redirects

#

# If you need to redirect some pages, or set a canonical non-www to

# www redirect (or vice versa), place that code here. Ensure those

# redirects use the correct RewriteRule syntax and the [R=301,L] flags.

#

## End - Custom redirects

  

##

# Uncomment the following line if your webserver's URL

# is not directly related to physical file paths.

# Update Your Joomla! Directory (just / for root).

##

  

# RewriteBase /

  

## Begin - Joomla! core SEF Section.

#

# PHP FastCGI fix for HTTP Authorization, required for the API application

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

# -- SEF URLs for the API application

# If the requested path starts with /api, the file is not /api/index.php

# and the request has not already been internally rewritten to the

# api/index.php script

RewriteCond %{REQUEST_URI} ^/api/

RewriteCond %{REQUEST_URI} !^/api/index\.php

# and the requested path and file doesn't directly match a physical file

RewriteCond %{REQUEST_FILENAME} !-f

# and the requested path and file doesn't directly match a physical folder

RewriteCond %{REQUEST_FILENAME} !-d

# internally rewrite the request to the /api/index.php script

RewriteRule .* api/index.php [L]

# -- SEF URLs for the public frontend application

# If the requested path and file is not /index.php and the request

# has not already been internally rewritten to the index.php script

RewriteCond %{REQUEST_URI} !^/index\.php

# and the requested path and file doesn't directly match a physical file

RewriteCond %{REQUEST_FILENAME} !-f

# and the requested path and file doesn't directly match a physical folder

RewriteCond %{REQUEST_FILENAME} !-d

# internally rewrite the request to the index.php script

RewriteRule .* index.php [L]

#

## End - Joomla! core SEF Section.

</IfModule>

  

## These directives are only enabled if the Apache mod_rewrite module is disabled

<IfModule !mod_rewrite.c>

<IfModule mod_alias.c>

# When Apache mod_rewrite is not available, we instruct a temporary redirect

# of the start page to the front controller explicitly so that the website

# and the generated links can still be used.

RedirectMatch 302 ^/$ /index.php/

# RedirectTemp cannot be used instead

</IfModule>

</IfModule>

  

## GZIP

## These directives are only enabled if the Apache mod_headers module is enabled.

## This section will check if a .gz file exists and if so will stream it

##     directly or fallback to gzip any asset on the fly

## If your site starts to look strange after enabling this file, and you see

##     ERR_CONTENT_DECODING_FAILED in your browser console network tab,

##     then your server is already gzipping css and js files and you don't need this

##     block enabled in your .htaccess

<IfModule mod_headers.c>

# Serve gzip compressed CSS files if they exist

# and the client accepts gzip.

RewriteCond "%{HTTP:Accept-encoding}" "gzip"

RewriteCond "%{REQUEST_FILENAME}\.gz" -s

RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

  

# Serve gzip compressed JS files if they exist

# and the client accepts gzip.

RewriteCond "%{HTTP:Accept-encoding}" "gzip"

RewriteCond "%{REQUEST_FILENAME}\.gz" -s

RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

  

# Serve correct content types, and prevent mod_deflate double gzip.

RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]

RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]

  

<FilesMatch "(\.js\.gz|\.css\.gz)$">

# Serve correct encoding type.

Header set Content-Encoding gzip

  

# Force proxies to cache gzipped &

# non-gzipped css/js files separately.

Header append Vary Accept-Encoding

</FilesMatch>

</IfModule>

Drupal 7​

Plik .htaccess w Drupal 7 zawiera podstawową konfigurację zabezpieczeń i optymalizacji. Oto jego typowa zawartość:

# Use the following to prevent server signatures and directory browsing

ServerSignature Off

Options -Indexes

  

# Protect sensitive files

<FilesMatch "\.(htaccess|htpasswd)">

  Order Allow,Deny

  Deny from all

</FilesMatch>

  

# Protect files from being accessed directly

<FilesMatch "\.(txt|md|yml|json|xml)$">

  Order Allow,Deny

  Deny from all

</FilesMatch>

  

# Set a default timezone for PHP

SetEnv TZ Europe/Amsterdam

  

# Enable compression for better performance

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript text/javascript application/javascript

  

# Cache settings for better performance

<IfModule mod_headers.c>

  Header set Cache-Control "public, max-age=3600"

</IfModule>

Drupal 8​

Dla Drupal 8 plik .htaccess zawiera już dodatkowe ulepszenia i obsługuje nowe funkcje. Na przykład: obsługa HTTP/2, zwiększone bezpieczeństwo, konfiguracja dla działania z clean URLs oraz z pamięcią podręczną.

# Prevent server signature and directory browsing

ServerSignature Off

Options -Indexes

  

# Protect sensitive files

<FilesMatch "\.(htaccess|htpasswd|ini|log|conf)$">

  Order Allow,Deny

  Deny from all

</FilesMatch>

  

# Clean URLs support

RewriteEngine on

RewriteBase /

  

# Support for HTTP/2

<IfModule http2_module>

  Protocols h2 http/1.1

</IfModule>

  

# Cache control for assets

<IfModule mod_headers.c>

  Header set Cache-Control "public, max-age=86400, s-maxage=86400, must-revalidate"

</IfModule>

  

# Enable compression

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript application/javascript text/javascript

  

# Redirect trailing slashes for clean URLs

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_URI} /+$

RewriteRule ^(.*)/$ /$1 [R=301,L]

Drupal 9​

Dla Drupal 9 plik .htaccess zawiera dodatkowe ulepszenia umożliwiające pracę z nowszymi technologiami internetowymi, takimi jak obsługa HTTP/2 oraz bardziej rygorystyczne środki bezpieczeństwa.

# Prevent directory browsing and server signatures

ServerSignature Off

Options -Indexes

  

# Protect sensitive files

<FilesMatch "\.(htaccess|htpasswd|ini|log|conf)$">

  Order Allow,Deny

  Deny from all

</FilesMatch>

  

# Enable clean URLs (this is essential for Drupal to work properly)

RewriteEngine on

RewriteBase /

  

# Support for HTTP/2 and modern caching

<IfModule mod_http2.c>

  Protocols h2 http/1.1

</IfModule>

  

<IfModule mod_headers.c>

  Header set Cache-Control "public, max-age=86400, s-maxage=86400, must-revalidate"

</IfModule>

  

# Enable Gzip compression

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript text/javascript application/javascript

  

# Clean URLs support for Drupal

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_URI} /+$

RewriteRule ^(.*)/$ /$1 [R=301,L]

OpenCart​

Options +FollowSymlinks

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]

Magento (2.x)​

Magento posiada bardziej złożony plik .htaccess, który zawiera reguły dotyczące kompresji, pamięci podręcznej oraz zabezpieczeń. Przykład dla Magento 2:

<IfModule mod_php5.c>

php_flag memory_limit 756M

php_flag max_execution_time 18000

</IfModule>

  

<IfModule mod_rewrite.c>

Options +FollowSymLinks

RewriteEngine on

  

RewriteCond %{REQUEST_URI} !^/pub/

RewriteRule ^(.*)$ pub/$1 [L]

</IfModule>

PrestaShop (1.7.x)​

PrestaShop automatycznie generuje plik .htaccess podczas instalacji lub przy zmianie ustawień przyjaznych adresów URL:

# ~~start~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again

# .htaccess automatically generated by PrestaShop e-commerce open-source solution

# http://www.prestashop.com - http://www.prestashop.com/forums

  

<IfModule mod_rewrite.c>

<IfModule mod_env.c>

     SetEnv HTTP_MOD_REWRITE On

</IfModule>

  

RewriteEngine on

  

# Domain: www.example.com

RewriteRule . - [E=REWRITEBASE:/]

  

# API

RewriteRule ^api$ api/ [L]

RewriteRule ^api/(.*)$ %{ENV:REWRITEBASE}webservice/dispatcher.php?url=$1 [QSA,L]

  

# Images

RewriteRule ^([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$1$2$3.jpg [L]

RewriteRule ^([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$1$2$3$4.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$1$2$3$4$5.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$1$2$3$4$5$6.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.jpg [L]

RewriteRule ^c/([0-9]+)(\-[\.*_a-zA-Z0-9-]*)(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2$3.jpg [L]

RewriteRule ^c/([a-zA-Z_-]+)(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2.jpg [L]

  

# AlphaImageLoader for IE and fancybox

RewriteRule ^images_ie/?([^/]+)\.(jpe?g|png|gif)$ js/jquery/plugins/fancybox/images/$1.$2 [L]

  

# Dispatcher

RewriteCond %{REQUEST_FILENAME} -s [OR]

RewriteCond %{REQUEST_FILENAME} -l [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^.*$ - [NC,L]

RewriteRule ^.*$ %{ENV:REWRITEBASE}index.php [NC,L]

</IfModule>

  

<IfModule mod_headers.c>

<FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|svg)$">

     Header set Access-Control-Allow-Origin "*"

</FilesMatch>

</IfModule>

  

<IfModule mod_expires.c>

ExpiresActive On

ExpiresByType image/gif "access plus 1 month"

ExpiresByType image/jpeg "access plus 1 month"

ExpiresByType image/png "access plus 1 month"

ExpiresByType text/css "access plus 1 week"

ExpiresByType text/javascript "access plus 1 week"

ExpiresByType application/javascript "access plus 1 week"

ExpiresByType application/x-javascript "access plus 1 week"

ExpiresByType image/x-icon "access plus 1 year"

ExpiresByType image/svg+xml "access plus 1 year"

ExpiresByType image/vnd.microsoft.icon "access plus 1 year"

ExpiresByType application/font-woff "access plus 1 year"

ExpiresByType application/x-font-woff "access plus 1 year"

ExpiresByType font/woff2 "access plus 1 year"

ExpiresByType application/vnd.ms-fontobject "access plus 1 year"

ExpiresByType font/opentype "access plus 1 year"

ExpiresByType font/ttf "access plus 1 year"

ExpiresByType font/otf "access plus 1 year"

ExpiresByType application/x-font-ttf "access plus 1 year"

ExpiresByType application/x-font-otf "access plus 1 year"

</IfModule>

  

<IfModule mod_headers.c>

Header unset Etag

</IfModule>

FileETag none

  

<IfModule mod_deflate.c>

<IfModule mod_filter.c>

     AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/x-javascript font/ttf application/x-font-ttf font/otf application/x-font-otf font/opentype image/svg+xml

</IfModule>

</IfModule>

  

# If rewrite mod isn't enabled

ErrorDocument 404 /index.php?controller=404

  

# ~~start~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again

# .htaccess automatically generated by PrestaShop e-commerce open-source solution

# http://www.prestashop.com - http://www.prestashop.com/forums

  

<IfModule mod_rewrite.c>

<IfModule mod_env.c>

     SetEnv HTTP_MOD_REWRITE On

</IfModule>

  

RewriteEngine on

  

# Domain: www.example.com

RewriteRule . - [E=REWRITEBASE:/]

  

# API

RewriteRule ^api$ api/ [L]

RewriteRule ^api/(.*)$ %{ENV:REWRITEBASE}webservice/dispatcher.php?url=$1 [QSA,L]

  

# Images

RewriteRule ^([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$1$2$3.jpg [L]

RewriteRule ^([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$1$2$3$4.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$1$2$3$4$5.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$1$2$3$4$5$6.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.jpg [L]

RewriteRule ^c/([0-9]+)(\-[\.*_a-zA-Z0-9-]*)(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2$3.jpg [L]

RewriteRule ^c/([a-zA-Z_-]+)(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2.jpg [L]

  

# AlphaImageLoader for IE and fancybox

RewriteRule ^images_ie/?([^/]+)\.(jpe?g|png|gif)$ js/jquery/plugins/fancybox/images/$1.$2 [L]

  

# Dispatcher

RewriteCond %{REQUEST_FILENAME} -s [OR]

RewriteCond %{REQUEST_FILENAME} -l [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^.*$ - [NC,L]

RewriteRule ^.*$ %{ENV:REWRITEBASE}index.php [NC,L]

</IfModule>

  

<IfModule mod_headers.c>

<FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|svg)$">

     Header set Access-Control-Allow-Origin "*"

</FilesMatch>

</IfModule>

  

<IfModule mod_expires.c>

ExpiresActive On

ExpiresByType image/gif "access plus 1 month"

ExpiresByType image/jpeg "access plus 1 month"

ExpiresByType image/png "access plus 1 month"

ExpiresByType text/css "access plus 1 week"

ExpiresByType text/javascript "access plus 1 week"

ExpiresByType application/javascript "access plus 1 week"

ExpiresByType application/x-javascript "access plus 1 week"

ExpiresByType image/x-icon "access plus 1 year"

ExpiresByType image/svg+xml "access plus 1 year"

ExpiresByType image/vnd.microsoft.icon "access plus 1 year"

ExpiresByType application/font-woff "access plus 1 year"

ExpiresByType application/x-font-woff "access plus 1 year"

ExpiresByType font/woff2 "access plus 1 year"

ExpiresByType application/vnd.ms-fontobject "access plus 1 year"

ExpiresByType font/opentype "access plus 1 year"

ExpiresByType font/ttf "access plus 1 year"

ExpiresByType font/otf "access plus 1 year"

ExpiresByType application/x-font-ttf "access plus 1 year"

ExpiresByType application/x-font-otf "access plus 1 year"

</IfModule>

  

<IfModule mod_headers.c>

Header unset Etag

</IfModule>

FileETag none

  

<IfModule mod_deflate.c>

<IfModule mod_filter.c>

     AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/x-javascript font/ttf application/x-font-ttf font/otf application/x-font-otf font/opentype image/svg+xml

</IfModule>

</IfModule>

  

# If rewrite mod isn't enabled

ErrorDocument 404 /index.php?controller=404

Shopify, Squarespace, Adobe Commerce i inne platformy w chmurze​

Shopify, Squarespace, Adobe Commerce (dawniej Magento Commerce) to platformy chmurowe, które nie zapewniają bezpośredniego dostępu do pliku .htaccess. Wszystkie ustawienia konfiguruje się za pomocą panelu administracyjnego.

Innymi przykładami takich usług są Wix, Weebly, BigCommerce i Jimdo. Te platformy umożliwiają użytkownikom tworzenie i optymalizację stron internetowych za pomocą wizualnych interfejsów, bez konieczności ręcznej edycji plików konfiguracyjnych serwera.

Potrzebujesz pomocy z plikiem .htaccess?​

Jeśli nie masz pewności, z jakiego systemu CMS korzysta Twoja strona lub jak bezpiecznie przywrócić uszkodzony plik .htaccess, jesteśmy tu, aby Ci pomóc.

Wsparcie techniczne dla naszych klientów jest całkowicie bezpłatne i dostępne 24/7/365. Wystarczy, że utworzysz zgłoszenie, a nasz zespół szybko się Tobą zajmie.

Więcej informacji o zakresie pomocy znajdziesz w naszej polityce wsparcia.

Szukasz panelu do zarządzania hostingiem? Obie opcje — FASTPANEL i CyberPanel — są popularne wśród administratorów, ale FASTPANEL wygrywa pod względem kluczowych parametrów: wygody, wydajności, kompatybilności i bezpieczeństwa.

FASTPANEL — panel stworzony dla prostoty, stabilności i elastyczności​

FASTPANEL to nowoczesny panel do zarządzania serwerami i stronami internetowymi, charakteryzujący się lekkością, stabilną architekturą oraz rozbudowanymi narzędziami dostępnymi od razu po instalacji. Został stworzony z myślą o maksymalnym komforcie pracy administratora przy jednoczesnym minimalnym zużyciu zasobów serwera.

W przeciwieństwie do CyberPanel, który bazuje na OpenLiteSpeed i posiada pewne ograniczenia, FASTPANEL oferuje stabilne, elastyczne i w pełni kompatybilne środowisko dla większości popularnych systemów CMS i aplikacji PHP. Dodatkowo, dzięki trybowi reverse proxy, obsługuje niezawodnie każdy backend nie oparty na PHP.

✅ 1. Uniwersalność i kompatybilność​

• Szeroka obsługa systemów operacyjnych: działa na Debian 9–12, Ubuntu 18.04–24.04, CentOS 7, AlmaLinux 8, RockyLinux 8.

• Szybka instalacja: trwa 3–7 minut, nie wymaga restartu serwera, uruchamiana jedną komendą.

• Działa na większości VPS-ów i serwerów dedykowanych bez potrzeby dostosowywania lub stosowania niestandardowych rozwiązań.

⚡ 2. Minimalne obciążenie na serwerze​

• Zajmuje tylko ~100 MB miejsca na dysku i zużywa ~170 MB RAM po instalacji.

• FASTPANEL — świetny wybór do oszczędzania zasobów, szczególnie w przypadku budżetowych VPS.

• Porównanie: CyberPanel zużywa prawie 5 razy więcej miejsca i 1,5 razy więcej pamięci RAM.

🔧 3. Klasyczny i elastyczny zestaw serwerowy​

• Używa Nginx (frontend) + Apache (backend) z PHP-FPM, co zapewnia:

• Szybkie serwowanie plików statycznych;

• Stabilne działanie stron PHP;

• Prostą konfigurację .htaccess i mod_rewrite.

• Obsługuje PHP od wersji 5.3 do 8.4, z możliwością przypisania różnych wersji PHP do różnych stron.

🛠️ 4. Bogata funkcjonalność „prosto z pudełka” (OOTB)​

• Rozbudowany menedżer plików — szybki i z nowoczesnym interfejsem.

• Zarządzanie bazami danych przez wbudowany phpMyAdmin/phpPgAdmin.

• Serwer pocztowy z pełnoprawnym webmailem (Exim + Dovecot + RoundCube).

• Kopie zapasowe:

• Bezpłatne backupy różnicowe;

• Obsługa chmur: Dropbox, Google Drive, FTP, SCP;

• Integracja z FASTBACKUP.

🔒 5. Wysokie bezpieczeństwo domyślnie​

• Web firewall.

• Skaner malware.

• 2FA (uwierzytelnianie dwuskładnikowe).

• Izolacja stron na poziomie systemowym — każda działa pod osobnym użytkownikiem.

• Możliwość udzielenia dostępu programiście tylko do jednej strony, bez ryzyka dla reszty.

🌍 6. Intuicyjny i nowoczesny interfejs​

• Współczesny UI z przejrzystą strukturą.

• Odpowiedni zarówno dla początkujących, jak i profesjonalistów.

• Obsługa 18 języków, w tym angielski, niemiecki, hiszpański, portugalski i inne.

📊 7. Monitorowanie i integracje​

• Obsługuje integrację z AWStats i Prometheus (Prometheus wymaga rozszerzonej licencji)

• Czytelne wykresy obciążenia, zużycia zasobów i logów.

🤝 8. Niezawodne wsparcie i aktualna dokumentacja​

• Bezpłatne wsparcie 24/7 dla kwestii związanych z panelem.

• Płatne wsparcie administracyjne dla ogólnych zagadnień serwerowych.

• Średni czas odpowiedzi: poniżej 5 minut.

• Szczegółowa i czytelna dokumentacja, w przeciwieństwie do skomplikowanych poradników CyberPanel.

💰 9. Przejrzysta i elastyczna polityka cenowa​

• Bezpłatna licencja z pełną funkcjonalnością podstawową.

• Licencja rozszerzona:

  ◦ €4,20 miesięcznie
  ◦ €46,20 rocznie
  ◦ €99 dożywotnio

• W przeciwieństwie do CyberPanel, FASTPANEL nie wymaga osobnych opłat za takie moduły jak menedżer plików czy WP Manager.

✅ Dlaczego ludzie wybierają FASTPANEL:​

• Prostota i stabilność;

• Bogata funkcjonalność bez dodatkowych kosztów;

• Niskie wymagania systemowe;

• Szybkie i pomocne wsparcie techniczne oraz wysoki poziom bezpieczeństwa;

• Świetna wydajność w rzeczywistych projektach.

Główne różnice między FASTPANEL a CyberPanel​

Zyskaj wydajność — bez zbędnych kosztów i skomplikowanych rozwiązań​

FASTPANEL to zaawansowane, a zarazem intuicyjne narzędzie do zarządzania serwerami, które zapewnia połączenie wygody, stabilności i wysokiej wydajności.
Instalujesz raz — i masz dostęp do pełnego zestawu funkcji, bez ukrytych ograniczeń i konieczności wykupowania dodatkowych subskrypcji.

Dla wszystkich klientów kodu.cloud rozszerzona licencja FASTPANEL jest dostarczana bezpłatnie przy wynajmie dowolnego serwera (VPS lub dedykowanego) — bez limitów, bez haczyków.

👉 Wybierz swój VPS lub serwer dedykowany i zacznij już dziś. Żadnych subskrypcji — tylko wydajność.

Jeśli chodzi o wybór usługi hostingowej do wynajmu serwerów dedykowanych lub tańszego VPS, ważne jest, aby wziąć pod uwagę kilka kluczowych czynników. W tym artykule omówimy dokładnie, na co należy zwrócić uwagę przy podejmowaniu decyzji, aby uzyskać wysokiej jakości i niezawodną usługę.

1. SLA (Service Level Agreement) — umowa o gwarantowanym poziomie świadczenia usług​

SLA to umowa określająca poziom dostępności i wydajności, jakiego możesz oczekiwać od dostawcy hostingu. Przed wyborem usługodawcy sprawdź, czy umowa SLA obejmuje:

• Gwarantowany czas pracy — idealny do wyboru usługi hostingowej z minimalnym czasem przestoju.
• Czas reakcji pomocy technicznej — ważne jest, aby dostawca szybko reagował w przypadku awarii.
• Ilość dostarczanych zasobów — w tym moc obliczeniowa, pamięć, przestrzeń dyskowa itp.

Dobrze zdefiniowane SLA gwarantuje stabilność przy minimalnych zakłóceniach i wysoką jakość usług, co jest niezwykle istotne dla biznesów online.

2. Centrum danych: lokalizacja i bezpieczeństwo​

Centrum danych jest podstawą hostingu, ponieważ od jego infrastruktury zależy nie tylko stabilność serwerów, ale także bezpieczeństwo danych.

• Lokalizacja centrum danych. Wybierz dostawcę z centrum danych, które znajduje się fizycznie blisko twojego głównego rynku. Może to poprawić szybkość dostępu i zmniejszyć opóźnienia.
• Poziom bezpieczeństwa. Upewnij się, że centrum danych jest wyposażone w aktualne systemy bezpieczeństwa, w tym systemy ochrony przed atakami DDoS, zasilanie awaryjne, systemy chłodzenia i ochronę fizyczną.

Wybierając usługę hostingową do wynajmu serwerów dedykowanych i VPS, należy zwrócić szczególną uwagę na reputację i licencje centrum danych, które potwierdzają jego niezawodność i zgodność z międzynarodowymi standardami.

3. Wsparcie 24/7 — klucz do nieprzerwanego działania​

Profesjonalne i szybkie wsparcie techniczne to jeden z najważniejszych elementów niezawodnego hostingu. Dostawca powinien oferować:

• Wsparcie techniczne 24/7. Im szybciej rozwiązywane są problemy, tym mniej czasu traci się na usuwanie awarii.
• Różne kanały komunikacji: czat, telefon, email. Pozwala to szybko wybrać najwygodniejszy sposób komunikacji w zależności od sytuacji.
• Wsparcie dla różnych technologii. Kluczowe, aby wsparcie mogło pomóc w instalacji i konfiguracji określonych aplikacji lub technologii (na przykład instalacja i konfiguracja VPS, praca z serwerami WWW, bazami danych itp.)

Jakość wsparcia technicznego wpływa nie tylko na komfort użytkowania, ale także na szybkość przywracania działania serwera w przypadku awarii.

4. Dostępne taryfy i opcje rozszerzenia​

Wybierając hosting dla serwerów dedykowanych i VPS, warto myśleć nie tylko o bieżących potrzebach, ale także o przyszłym rozwoju. Skalowalność to kluczowy aspekt, który pozwoli dostosować zasoby do rosnących wymagań biznesowych. Zwróć uwagę na:

• Kwestie cenowe: tani VPS lub wynajem serwerów dedykowanych o odpowiedniej pojemności — szukaj równowagi między ceną a jakością.
• Skalowalność: możliwość szybkiego zwiększenia zasobów (pamięci, procesora, przestrzeni dyskowej) bez znaczących zakłóceń w działalności firmy.

Wybór taniego VPS lub wynajmu serwera dedykowanego zależy od konkretnych potrzeb firmy i ważne jest, aby dostawca oferował optymalne warunki pod względem ceny i funkcjonalności.

Podsumowanie​

Wybierając hosting dla serwerów dedykowanych lub VPS, warto zwrócić uwagę na kluczowe aspekty: SLA, bezpieczeństwo centrum danych i jakość wsparcia technicznego – wpływają na stabilność działania twojej strony lub aplikacji. Nie zapomnij również o stawkach i skalowalności, aby twój hosting mógł rozwijać się wraz z twoją firmą.

Dbając o te elementy, zapewnisz swojej firmie niezawodność i bezpieczeństwo na długie lata.

Szukasz solidnego i korzystnego cenowo hostingu? Sprawdź nasze taryfy i wybierz idealne rozwiązanie dla serwerów dedykowanych i VPS – z niezawodnym wsparciem i wysokim SLA.

Wprowadzenie​

Wybór odpowiedniego hostingu to kluczowa decyzja dla każdej firmy czy projektu. Czy lepiej postawić na VPS, czy zainwestować w serwer dedykowany? Łatwo tu popełnić błąd — albo przepłacimy, albo staniemy w obliczu braku zasobów. W tym artykule omówimy, kiedy tani VPS spełni swoje zadanie, a kiedy nie obejdzie się bez bare-metal.

VPS i serwer dedykowany – czym się różnią?​

• VPS (Prywatny serwer wirtualny) to wydzielona część fizycznego serwera z określonymi zasobami. Choć działa jak samodzielna maszyna, współdzieli „sprzęt” z innymi użytkownikami.
• Serwer dedykowany to natomiast cały fizyczny serwer, którego pełna moc obliczeniowa jest do twojej wyłącznej dyspozycji.

Sprawdźmy teraz, kiedy VPS będzie wystarczający, a kiedy warto zainwestować w serwer dedykowany.

Kiedy VPS jest idealnym wyborem​

1. Małe i średnie projekty​

Jeśli twoja strona lub aplikacja nie generuje dużych obciążeń, VPS to świetny wybór. Jest tańszy, a zasoby są wystarczające do większości zadań.

2. Środowisko testowe i deweloperskie​

VPS jest idealny do rozwoju, testowania i eksperymentowania. Możesz łatwo wdrożyć serwer, przywracać zmiany i instalować różne systemy operacyjne.

3. Startupy i rozwijające się projekty​

Jeśli twój projekt dopiero nabiera tempa, VPS pozwoli ci zacząć bez dużych kosztów. Wraz ze wzrostem zapotrzebowania możesz przejść na bardziej wydajny plan lub serwer dedykowany.

4. VPN/proxy​

Usługi takie jak VPN czy proxy nie wymagają dużej mocy obliczeniowej, dlatego VPS poradzi sobie z nimi bez problemu.

Kiedy serwer dedykowany jest koniecznością​

1. Bardzo obciążone projekty​

Jeśli twoja strona internetowa, CRM lub baza danych obsługuje tysiące użytkowników na minutę, VPS może sobie nie poradzić. Serwer dedykowany zapewni stabilność i odpowiednią wydajność.

2. Sklepy internetowe, usługi finansowe i SaaS​

Jeśli masz sklep internetowy, platformę finansową lub projekt SaaS, spadek prędkości = utrata przychodów. Serwer dedykowany gwarantuje maksymalną wydajność.

3. Projekty wymagające wysokiego poziomu bezpieczeństwa​

Jeśli przetwarzasz dane osobowe, informacje finansowe lub firmowe, lepszym wyborem będzie serwer dedykowany, który zapewnia wyższy poziom izolacji i bezpieczeństwa.

4. Serwery gier i streaming​

Jeśli planujesz uruchomić serwery gier (takie jak Minecraft, Valheim lub inne gry, które lubisz) lub przesyłać strumieniowo wideo, możesz potrzebować dedykowanej karty graficznej, szybszego magazynu i stabilnego połączenia o większej przepustowości. VPS może nie być w stanie sprostać tym wymaganiom.

Podsumowanie: co wybrać?​

VPS – jeśli potrzebujesz równowagi między ceną a zasobami: strony internetowe, blogi, małe serwisy, testy.

Serwer dedykowany – gdy kluczowa jest moc i stabilność: niezbędny dla dużych projektów, rozbudowanych baz danych i zaawansowanych produktów SaaS.

Jeśli masz wątpliwości, co wybrać, zawsze możesz zacząć od VPS i przejść na serwer dedykowany, gdy obciążenie wzrośnie. Najważniejsze to postawić na sprawdzonego dostawcę hostingu, który zagwarantuje niezawodność i wydajność.

Szukasz niezawodnego VPS lub serwer dedykowany w świetnej cenie? Wybierz kodu.cloud – potężne plany, całodobowe wsparcie z responsywnym zespołem zawsze gotowym pomóc w przypadku jakichkolwiek problemów z serwerem i niezawodna wydajność przez cały okres dzierżawy!

Jeśli przeglądarka wyświetla komunikat DNS_PROBE_FINISHED_NXDOMAIN, oznacza to, że nie może określić adresu IP żądanej strony. Może się to zdarzyć z różnych powodów:

• Nazwa domeny nie istnieje w serwerach DNS lub jej rejestracja wygasła.
• Serwer obsługujący strefę domenową jest niedostępny.
• DNS jest nieprawidłowo skonfigurowany na urządzeniu.
• Zakłócenia spowodowane przez VPN, antywirusa lub zaporę sieciową.
• Nieprawidłowe działanie dostawcy usług internetowych.

Towarzyszący tekst błędu może wyglądać nieco inaczej w różnych przeglądarkach:

• Google Chrome: „Ta witryna jest nieosiągalna”.
• Mozilla Firefox: „Niestety, nie udało się odnaleźć tej strony”.
• Microsoft Edge: „Niestety… nie można przejść do tej strony”.
• Safari: „Safari nie może znaleźć serwera”.

Jak określić przyczynę błędu?​

1. Sprawdź status domeny​

Na początek upewnij się, że wpisany adres jest poprawny. Jeśli wszystko się zgadza, sprawdź rejestrację domeny za pomocą ICANN Lookup. Wprowadź URL i zobacz, czy domena jest aktywna.

2. Dostępność przez proxy​

Spróbuj otworzyć stronę, korzystając z proxy, VPN lub innej sieci (np. mobilnej). Jeśli w tym przypadku strona działa, oznacza to, że problem najprawdopodobniej leży w ustawieniach twojego urządzenia lub sieci.

Jak naprawić błąd DNS_PROBE_FINISHED_NXDOMAIN​

Czyszczenie pamięci podręcznej​

Czasami przeglądarka lub system przechowuje nieaktualne wpisy DNS. Ich wyczyszczenie może pomóc w odświeżeniu ustawień.

• Windows:

1. Otwórz Wiersz poleceń (jako administrator): Start → wpisz cmd w wyszukiwaniu i naciśnij Enter. 
2. Uruchom polecenie:

ipconfig /flushdns

3. Uruchom ponownie przeglądarkę.

• macOS:

1. Otwórz Terminal: na klawiaturze naciśnij cmd + spacja, wpisz Terminal i naciśnij Enter.
2. Wpisz:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

3. Naciśnij klawisz Enter.

• Google Chrome:

1. W pasku adresu przeglądarki wpisz:

chrome://net-internals/#dns

2. Kliknij Clear host cache.

Aktualizacja adresu IP​

Jeśli wyczyszczenie pamięci podręcznej nie pomogło, spróbuj zmienić adres IP.

• Windows:

ipconfig /release
ipconfig /renew
netsh int ip set dns
netsh winsock reset

Zrestartuj system.

• macOS:

1. Przejdź do Ustawienia systemowe → Sieć.
2. Kliknij w usługę sieciową → Szczegóły → TCP/IP.
3. Kliknij Odśwież dzierżawę DHCP.

Korzystanie z alternatywnych serwerów DNS​

Problem może być związany z serwerami DNS dostawcy internetu. Spróbuj użyć Google DNS (8.8.8.8, 8.8.4.4) lub Cloudflare DNS (1.1.1.1, 1.0.0.1).

• Windows:

1. Otwórz Panel sterowania → Sieć i Internet → Centrum sieci i udostępniania.
2. Wybierz aktywne połączenie → Właściwości
3. W sekcji IP w wersji 4 (TCP/IPv4) wpisz:

• Podstawowy DNS: 8.8.8.8

• Dodatkowy DNS: 8.8.4.4

• macOS:

1. Otwórz Ustawienia systemowe.
2. Przejdź do sekcji Sieć.
3. Wybierz aktywne połączenie (np. Wi-Fi lub Ethernet) w lewym panelu.
4. Kliknij Szczegóły.
5. Przejdź do zakładki DNS.
6. W sekcji Serwery DNS kliknij + i dodaj następujące serwery DNS:

• 8.8.8.8 (Google DNS)
• 8.8.4.4 (Google DNS)

 lub

• 1.1.1.1 (Cloudflare DNS)
• 1.0.0.1 (Cloudflare DNS)

1. Kliknij OK, a następnie Zastosuj.

Ponowne uruchomienie usługi klienta DNS (Windows)​

1. Otwórz Wiersz poleceń jako administrator.
2. Wpisz:

net stop dnscache
net start dnscache

Sprawdzenie pliku hosts​

Plik hosts może zawierać nieprawidłowe wpisy blokujące dostęp do strony.

• Windows:

1. Otwórz Notatnik jako administrator.
2. Otwórz plik (Plik  →  Otwórz):

C:\Windows\System32\drivers\etc\hosts 

3. Usuń linie zawierające problematyczną domenę.

• macOS:

1. Otwórz plik hosts w edytorze tekstowym:

sudo nano /etc/hosts

2. Usuń linie zawierające problematyczną domenę.
3. Zapisz plik za pomocą skrótu Ctrl + O, a następnie wyjdź z edytora, naciskając Ctrl + X. 

Resetowanie flag Chrome​

Niektóre ukryte ustawienia przeglądarki mogły zostać zmienione.

1. W pasku adresu wpisz:

chrome://flags/

2. Kliknij Zresetuj wszystko.

Wyłączenie antywirusa i VPN​

Niektóre programy antywirusowe lub usługi VPN mogą blokować zapytania DNS. Tymczasowo je wyłącz i sprawdź, czy strona jest dostępna.

Sprawdzenie ustawień CDN​

Jeśli strona korzysta z Cloudflare lub innego CDN, spróbuj tymczasowo wyłączyć proxy dla tej domeny w panelu zarządzania CDN.

Restartowanie routera​

Czasami problem może dotyczyć routera. Spróbuj:

1. Wyłączyć router na 5 minut.
2. Włączyć go ponownie i sprawdzić połączenie.

Podsumowanie​

Błąd DNS_PROBE_FINISHED_NXDOMAIN jest związany z problemami DNS. Można go naprawić, czyszcząc pamięć podręczną, zmieniając serwery DNS, sprawdzając status domeny lub dostosowując ustawienia systemowe. Jeśli problem nadal występuje, skontaktuj się z dostawcą internetu.

Wprowadzenie​

Jeśli kiedykolwiek konfigurowałeś serwer pocztowy lub miałeś do czynienia z odwrotną weryfikacją DNS, prawdopodobnie spotkałeś się z rekordami PTR. Ale czym one właściwie są? Dlaczego często nie można samodzielnie skonfigurować rekordów PTR? Przyjrzyjmy się temu bliżej!

Co to jest rekord PTR?​

PTR (Pointer) — to typ rekordu DNS, który umożliwia konwersję adresu IP na odpowiadającą mu nazwę domeny. W przeciwieństwie do standardowych rekordów A, które mapują domenę na adres IP, rekordy PTR wskazują, do jakiej domeny przypisany jest dany adres IP.

Jak działa rekord PTR?​

Gdy serwer odbiera połączenie przychodzące, może zapytać odwrotny DNS (rDNS) o adres IP nadawcy. Jeśli rekord PTR jest skonfigurowany, otrzyma odpowiednią nazwę domeny. Jest to ważne dla:

• Konfigurowania serwerów pocztowych (serwery SMTP często wymagają PTR, aby poprawnie wysyłać wiadomości e-mail i nie zostać wrzuconym do spamu);
• Rozpoznawania adresów IP w logach i zwiększenia bezpieczeństwa;
• poprawnego działania niektórych usług zależnych od rDNS.

Dlaczego nie mogę samodzielnie skonfigurować rekordu PTR?​

Wielu użytkowników, którzy mają dostęp do zarządzania rekordami DNS, oczekuje, że będą w stanie utworzyć rekord PTR, tak jak rekord A lub CNAME. Jednak tu pojawia się kluczowy problem: Rekordy PTR nie są konfigurowane w hostingu DNS, lecz u dostawcy adresu IP (ISP, centrum danych lub dostawcy usług hostingowych).

Główne powody:​

1. Kontrola nad adresem IP – Rekordy PTR należą do właściciela puli adresów IP. Jeśli korzystasz z serwera dedykowanego lub VPS, właścicielem adresu IP jest twój dostawca hostingu, który powinien skonfigurować rekord PTR.
2. Brak dostępu do zarządzania rDNS – Nawet jeśli masz pełną kontrolę nad DNS swojej domeny, odwrotna strefa DNS (in-addr.arpa) jest zarządzana przez właściciela zakresu IP.
3. Wymagania dostawcy – Niektórzy dostawcy hostingu pozwalają na konfigurację PTR wyłącznie poprzez zgłoszenie do pomocy technicznej, a nie poprzez panel sterowania.
4. Dynamiczne adresy IP – Jeśli twój adres IP jest dynamiczny (np. w domowym połączeniu internetowym), twój dostawca prawdopodobnie nie pozwoli ci ustawić własnego rekordu PTR.

Jak skonfigurować rekord PTR?​

1. Skontaktuj się z dostawcą​

Aby stworzyć lub zmienić rekord PTR, należy skontaktować się z dostawcą hostingu lub ISP, który przypisał ci adres IP. Zwykle robi się to poprzez zgłoszenie do pomocy technicznej.

2. Podaj odpowiednią domenę​

Zazwyczaj dostawca wymaga, aby rekord PTR wskazywał na rzeczywistą domenę, która jest już skonfigurowana i rozwiązana w rekordzie A.

3. Sprawdź konfigurację​

Po zmianie rekordu PTR warto sprawdzić jego działanie za pomocą poniższej komendy:

Windows:

nslookup 123.123.123.123

Linux i MacOS:

dig -x 123.123.123.123

Podsumowanie​

Rekord PTR jest kluczowym elementem DNS, zwłaszcza dla serwerów pocztowych. Niemniej jednak, nie można go skonfigurować bez zgody właściciela adresu IP. Jeśli potrzebujesz utworzyć rekord PTR, skontaktuj się ze swoim dostawcą usług hostingowych, aby sprawdzić, czy istnieje możliwość jego konfiguracji. Prawidłowe ustawienie rekordu pomoże uniknąć problemów z dostarczaniem wiadomości e-mail i zwiększy wiarygodność twojego serwera.

Chcesz skutecznie przekierować użytkowników i wyszukiwarki na nowy adres URL? Przekierowanie 301 to twój najlepszy przyjaciel! Pomaga zachować pozycje SEO i uniknąć błędów 404. W tym artykule pokażemy, jak szybko i łatwo skonfigurować przekierowanie 301 w plikach .htaccess i na serwerach nginx.

Czym jest przekierowanie 301 i dlaczego jest potrzebne?​

Przekierowanie 301 to stałe przeniesienie z jednego adresu URL na inny. Jest niezbędne, gdy:

• Zmieniasz adres strony i chcesz zachować dotychczasowe pozycje w wyszukiwarkach.
• Łączysz kilka adresów URL w jeden.
• Chcesz uniknąć błędów 404 i utraty ruchu.

Jak skonfigurować przekierowanie 301 w .htaccess (Apache)​

1. Znajdź lub utwórz plik.htaccess

Plik.htaccess zazwyczaj znajduje się w katalogu głównym (roboczym) twojej strony. Jeśli go nie ma, utwórz nowy.

2. Dodaj następujący kod przekierowania

• Dla jednego URL:

Redirect 301 /old-page https://yoursite.com/new-page

• Dla przekierowania całej strony:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^oldsite\.com$ [NC]

RewriteRule ^(.*)$ https://newsite.com/$1 [L,R=301]

Zamień oldsite.com i newsite.com na odpowiednio starą i nową domenę twojej strony. 

3. Zapisz plik

Zmiany zostaną zastosowane natychmiast.

Jak skonfigurować przekierowanie 301 w Nginx​

1. Otwórz plik konfiguracyjny nginx swojej strony

Połącz się z serwerem przez SSH i otwórz odpowiedni plik w edytorze tekstowym nano:

sudo nano /etc/nginx/sites-available/your-site.com.conf

Zamień yoursite.com na domenę swojej witryny. 

Jeśli nie można znaleźć takiego pliku, można znaleźć lokalizację pliku konfiguracyjnego za pomocą polecenia:

sudo grep -irl name /etc/nginx

2. Dodaj reguły przekierowania do bloku server

• Dla jednego URL:

server {

listen 80;

server_name oldsite.com;

return 301 https://newsite.com/new-page;

}

• Dla przekierowania całej strony:

server {

listen 80;

server_name oldsite.com;

return 301 https://newsite.com$request_uri;

}

3. Zapisz zmiany i zastosuj je

Zapisz plik za pomocą skrótu klawiaturowego "Ctrl + o" i zamknij edytor nano za pomocą "Ctrl + x". Następnie wprowadź zmiany poleceniem:

sudo systemctl reload nginx

Jak sprawdzić, czy przekierowanie działa?​

Po skonfigurowaniu upewnij się, że przekierowanie 301 działa:

• Otwórz stary URL w przeglądarce.

Przejdź na stary URL i upewnij się, że zostałeś przekierowany na nowy adres.

• Skorzystaj z narzędzi online do testowania przekierowań, na przykład Redirect Checker.