Błąd „zbyt wiele przekierowań” oznacza, że witryna jest przekierowywana między różnymi adresami w sposób, który nigdy się nie zakończy. Często jest to wynikiem konkurencyjnych przekierowań, z których jedno próbuje wymusić HTTPS (SSL), a drugie przekierowuje z powrotem do HTTP (bez SSL) lub między formami adresu URL z www i bez www.
Jeśli używasz CMS, takiego jak Wordpress, Magento itp., wykorzystuje on base_url lub konfiguracji typu adresu URL w witrynie, możesz skończyć z konfiguracją w kodzie lub bazie danych, która powoduje konflikt z przekierowaniem w pliku .htaccess. Te sprzeczne przekierowania będą się przerzucać w tę i z powrotem i nigdy się nie kończą.
Twoja przeglądarka chroni Cię przed tym, zezwalając tylko na określoną liczbę przekierowań (często dziesięć lub więcej), zanim się podda i zgłosi komunikat o błędzie „zbyt wiele przekierowań”. To wygląda inaczej w Chrome, Firefox i innych przeglądarkach.
Firefox
Strona nie jest poprawnie przekierowywana. Wystąpił błąd podczas połączenia z
Chrome
Ta strona nie działa
Nawet narzędzie testowe curl domyślnie rezygnuje po 50 przekierowaniach.
Zwinięcie: Maksymalna (X) liczba obserwowanych przekierowań
curl -svILk https://www.example.com
....
* Maximum (50) redirects followedPierwszy krok:pamięć podręczna i pliki cookie
Jak pokazano w powyższych błędach przeglądarki, te zapętlone przekierowania mogą być również spowodowane przez pliki cookie w pamięci podręcznej przeglądarki, które przechowują stare przekierowania. Pierwszym krokiem w testowaniu byłoby wyczyszczenie pamięci podręcznej i plików cookie w przeglądarce. Jeśli wyczyściłeś już pamięć podręczną i pliki cookie w przeglądarce, czas przejść do bardziej zaawansowanego rozwiązywania problemów.
Korzystanie z narzędzi programistycznych do pętli przekierowań
Następnym krokiem w rozwiązywaniu problemów z tego rodzaju pętlami przekierowań jest użycie Narzędzi dla programistów w przeglądarce Firefox lub Chrome. Narzędzia te są zwykle otwierane przez naciśnięcie klawisza F12. Upewnij się, że wybrałeś Sieć w jednym z nich, a następnie ponownie załaduj stronę, z którą masz problem.
Po ponownym załadowaniu strony powinieneś zobaczyć serię przekierowań wymienionych w nowym oknie. Patrząc na przekierowania, możesz zobaczyć, czy przekierowują one między kilkoma różnymi rzeczami, czy przekierowują do tej samej rzeczy. Tak czy inaczej, możesz zobaczyć kroki prowadzące do błędu, a nie tylko błąd przeglądarki użytkownika końcowego.
Narzędzia programistyczne w Firefoksie
Używanie cURL do pętli przekierowań
W ramach pisania tego artykułu stworzyliśmy dość prosty skrypt Bash, którego można używać w dowolnym systemie uniksowym z curl Komenda. Używanie curl jest fajne, ponieważ nie buforuje rzeczy w taki sam sposób jak przeglądarki, więc czasami może dać ci inną perspektywę podczas rozwiązywania problemów.
Skopiuj poniższy tekst do preferowanego edytora tekstu i zapisz go jako redirects.sh .
#!/bin/bash
echo
for domain in $@; do
echo --------------------
echo $domain
echo --------------------
curl -sILk $domain | egrep 'HTTP|Loc' | sed 's/Loc/ -> Loc/g'
echo
doneNastępnie zaznacz redirects.sh plik jako wykonywalny.
chmod +x redirects.shMożesz uruchomić nasz skrypt, tak jak w poniższych przykładach, dodając swoją domenę po nazwie skryptu. Może nawet sprawdzać wiele domen i sprawdzać przekierowania każdego adresu URL, z kolei umieszczając nagłówek między oddzielnymi testowanymi domenami.
Przykładowe wyjście
./redirects.sh liquidweb.com
--------------------
liquidweb.com
--------------------
HTTP/1.1 301 Moved Permanently
-> Location: https://liquidweb.com/
HTTP/1.1 301 Moved Permanently
-> Location: https://www.liquidweb.com/
HTTP/1.1 200 OKPrzykład nieskończonego przekierowania z HTTP na HTTPS
./redirects.sh http://www.example.com
--------------------
http://www.example.com
--------------------
HTTP/1.1 301 Moved Permanently
-> Location: https://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: http://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: https://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: http://www.example.com/
HTTP/1.1 301 Moved Permanently
....
-> Location: https://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: http://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: https://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: http://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: https://www.example.com/Dodatkowa uwaga na temat typów przekierowań
Patrząc na zakręt Powyższe dane wyjściowe pokazują, że kod odpowiedzi HTTP to 301. Przekierowania 301 to „stałe” przekierowanie, co oznacza, że coś zostało trwale przeniesione i Ty lub Twoja przeglądarka musicie to wyszukać w nowej lokalizacji zarówno teraz, jak iw przyszłości. Przekierowania 302 to przekierowania „tymczasowe”, co oznacza, że coś zostało na razie przeniesione, ale nie zawsze może znajdować się w nowej lokalizacji.
Przekierowania 301 są najczęściej zapisywane jako przekierowania lub przepisywanie wpisów w pliku .htaccess. Jednak przekierowania 302, czy to zgodnie z projektem, czy konwencją, są często generowane w kodzie strony internetowej. Tak więc dobrą zasadą jest to, że 301 znajdują się w plikach .htaccess, a 302 są w kodzie witryny. Może to nie zawsze być prawdą, ale warto o tym pamiętać.
Przekierowania w pliku .htaccess
Plik .htaccess to plik konfiguracyjny używany do modyfikowania zachowania serwera Apache na katalog w witrynie/serwerze. Jest to plik konfiguracyjny na poziomie użytkownika i tylko niektóre konfiguracje Apache mogą być tutaj edytowane, chociaż przekierowania są powszechne.
Możesz mieć wiele plików .htaccess, które są przesyłane kaskadowo w serii katalogów. Jeśli masz .htaccess w katalogu nadrzędnym, a drugi w podkatalogu, oba wpłyną na podkatalog. W takich przypadkach ważne jest, aby pamiętać, gdzie nie masz plików .htaccess, aby zapobiec konfliktom między plikami .htaccess na różnych poziomach.
Poniżej znajduje się seria przykładów przekierowań, które pomogą w identyfikacji przekierowań w pliku .htaccess. Nie są to jedyne sposoby wykonywania tego rodzaju przekierowań, ale powinny one pokazać, jak wyglądają najpopularniejsze przekierowania, abyś mógł je rozpoznać, jeśli znajdują się w pliku .htaccess, z którym pracujesz.
Wymuś HTTPS
Poniższy kod .htaccess najpierw sprawdza, czy żądanie dotarło do serwera przy użyciu protokołu HTTP lub HTTPS. Jeśli żądanie nie używało protokołu HTTPS, konfiguracja poinformuje przeglądarkę, aby przekierowała do wersji HTTPS tej samej witryny i adresu URL, który był wcześniej żądany.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Wymuś HTTPS:za modułem równoważenia obciążenia lub serwerem proxy (CloudFlare/Incapsula/Sucuri/etc.)
Czasami możesz używać serwera proxy, takiego jak system równoważenia obciążenia lub zapora sieciowa, na przykład CloudFlare, Incapsula lub Sucuri. Można je skonfigurować tak, aby używały protokołu SSL na interfejsie, ale nie używały protokołu SSL na zapleczu. Aby to działało poprawnie, musisz sprawdzić nie tylko HTTPS w żądaniu, ale także, czy serwer proxy przekazał oryginalne żądanie HTTPS do serwera przy użyciu samego protokołu HTTP. Ta następująca reguła sprawdza, czy żądanie zostało przekazane z HTTPS, a jeśli tak, nie próbuje przekierować dodatkowego czasu.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Wymuś brak www
To przekierowanie sprawdza tylko, czy nazwa witryny została zażądana z www na początku nazwy domeny. Jeśli www jest uwzględniony, przepisuje żądanie i mówi przeglądarce, aby przekierowała do wersji innej niż www nazwy domeny.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Wymuś www
To ostatnie przekierowanie sprawdza, czy nazwa witryny nie została zażądana z www na początku nazwy domeny. Jeśli www nie jest uwzględniony, przepisuje żądanie i nakazuje przeglądarce przekierowanie do wersji www domeny.
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]WordPress
CMS WordPress używa pliku .htaccess do przepisywania adresów URL do index.php plik, ale definiuje adres URL strony internetowej jako wartość w bazie danych. Jeśli nie znasz jeszcze nazwy bazy danych używanej w witrynie, możesz ją wyszukać w głównej konfiguracji WordPressa (wp-config.php ).
Możesz także otworzyć plik w edytorze tekstu i poszukać tych wartości, ale z połączenia SSH możesz użyć programu grep . Daje to więcej niż tylko nazwę bazy danych, ale nazwa bazy danych jest najważniejsza dla tego, co musimy zrobić dalej.
grep DB wp-config.php
define('DB_NAME', 'wordpress_database');
define('DB_USER', 'wordpress_username');
define('DB_PASSWORD', 'Password');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');Tabela wp_options
Gdy znasz nazwę bazy danych, możesz spojrzeć na tabelę opcji bazy danych Wordpress, aby zobaczyć, jaki adres URL jest ustawiony w bazie danych. Tabela opcji może mieć dowolny przedrostek na początku nazwy tabeli, ale często jest to "wp_" domyślnie, więc pełna nazwa tabeli opcji to zwykle wp_options . Dwie ważne linie to dom i siteurl wiersze w tabeli opcji. Możesz je znaleźć za pomocą phpMyAdmin , lub inne narzędzie do zarządzania bazą danych, ale z wiersza poleceń możesz też po prostu uruchomić następujący mysql polecenie.
mysql -e 'show tables' wordpress_database | grep options
prefix_optionsSprawdzanie skonfigurowanego adresu URL
Z wiersza poleceń możesz sprawdzić, jakie są aktualne wartości domu i siteurl wiersze w tabeli opcji. Polecenie powinno wysłać ci i wyprowadzić jak w poniższym przykładzie. Ważną częścią jest to, że pasują one do siebie w większości przypadków i są tym, czego oczekujesz. Jeśli nie są one zgodne z oczekiwaniami, należy je odpowiednio zaktualizować.
mysql -e 'select * from wp_options where option_name rlike "home|siteurl"' wordpress_database
+-----------+-------------+----------------------------------+----------+
| option_id | option_name | option_value | autoload |
+-----------+-------------+----------------------------------+----------+
| 36 | home | http://www.example.com | yes |
| 1 | siteurl | http://www.example.com | yes |
+-----------+-------------+----------------------------------+----------+Aktualizacja skonfigurowanego adresu URL
Następujące polecenie zaktualizuje dwa wiersze wp_options tabeli dla danej bazy danych na nowy adres URL. To polecenie powinno pasować do większości sytuacji, w których musisz zaktualizować lub poprawić adres URL skonfigurowany dla witryny Wordpress. Aktualizacja base_urls skonfigurowane w Wordpress Multisite wykracza poza zakres tego artykułu, ale wymagałoby aktualizacji wielu wp_option wpisz tabele.
mysql -e 'update wp_options set option_value="https://www.example.com" where option_name rlike "home|siteurl"' wordpress_databaseMagento
Nazwa bazy danych Magento jest skonfigurowana w jednym z następujących plików, local.xml lub env.php . Możesz również skonfigurować prefiks dla nazw tabel bazy danych Magento, ale zazwyczaj nie jest on ustawiany. Oczekiwana nazwa głównej tabeli konfiguracyjnej bazy danych to po prostu core_config_data .
# Version 1.x
app/etc/local.xml
# Version 2.x
app/etc/env.phpTabela core_config_data
Istnieje wiele potencjalnych adresów URL, które można skonfigurować, ale wszystkie mają "base_url jako część linii w bazie danych. Skonfigurowane podstawowe adresy URL będą bezpiecznymi i niezabezpieczonymi adresami URL, ale możesz także skonfigurować adresy URL dla obrazów, plików motywów, a nawet skonfigurować oddzielny adres URL dla obszaru administracyjnego witryny. Możesz je ponownie znaleźć za pomocą narzędzia do zarządzania bazą danych, ale z wiersza poleceń możesz uruchomić coś takiego.
mysql -e 'select * from core_config_data where path rlike "base_url"' magento_database
+-----------+---------+----------+-----------------------+----------------------------+
| config_id | scope | scope_id | path | value |
+-----------+---------+----------+-----------------------+----------------------------+
| 3 | default | 0 | web/unsecure/base_url | http://www.example.com |
| 4 | default | 0 | web/secure/base_url | http://www.example.com |
+-----------+---------+----------+-----------------------+----------------------------+Aby zaktualizować base_urls w bazie danych Magento uruchomiłbyś coś takiego jak poniższe polecenie. Aktualizowanie base_urls Magento Multisite również wykracza poza zakres tego artykułu, ale wymagałoby dodatkowego odwołania się do konkretnego scope_id wartość dla danej strony internetowej lub sklepu skonfigurowanego w bazie danych Magento.
mysql -e 'update core_config_data set value="https://www.example.com" where path rlike "web/.*/base_url"' magento_databaseZawijanie wszystkiego
W przypadku adresów URL skonfigurowanych w bazie danych, jak pokazano powyżej, warto zauważyć, że te systemy CMS zapewniają również własne metody przekierowań w kodzie witryny. Jeśli na przykład masz przekierowanie .htaccess, które przekierowuje do adresu URL, który nie jest zgodny z zawartością bazy danych, możesz skończyć z nieskończoną pętlą przekierowań, jak opisano wcześniej. Jednak teraz wiesz, jak wyglądają niektóre typowe przekierowania .htaccess i gdzie znaleźć skonfigurowane adresy URL w niektórych bazach danych oprogramowania CMS. Jesteś również dobrze przygotowany do testowania, badania i potwierdzania, czy te rzeczy działają wspólnie lub przeciwko sobie, a także do podjęcia pewnych kroków w celu ich rozwiązania.
