Chyba „příliš mnoho přesměrování“ znamená, že web je stále přesměrován mezi různými adresami způsobem, který se nikdy nedokončí. Často je to důsledek konkurenčních přesměrování, z nichž jedno se snaží vynutit HTTPS (SSL) a druhé přesměrování zpět na HTTP (non-SSL) nebo mezi www a non-www formy adresy URL.
Pokud používáte CMS jako Wordpress, Magento atd., který využívá base_url nebo konfiguraci typu URL na webu, můžete skončit s konfigurací v kódu nebo databázi v konfliktu s přesměrováním v souboru .htaccess. Tato konfliktní přesměrování se budou převracet tam a zpět a nikdy nebudou dokončena.
Váš prohlížeč vás před tím chrání tím, že povolí pouze určitý počet přesměrování (často deset nebo více), než to vzdá a ohlásí chybovou zprávu „příliš mnoho přesměrování“. To se mezi Chrome, Firefox a dalšími prohlížeči zobrazuje odlišně.
Firefox
Stránka se nepřesměrovává správně. Během připojení k
Chrome
Tato stránka nefunguje
Dokonce i testovací utilitacurl ve výchozím nastavení se vzdá po 50 přesměrováních.
Kudrování: Maximální počet (X) následovaných přesměrování
curl -svILk https://www.example.com
....
* Maximum (50) redirects followedPrvní krok:Mezipaměť a soubory cookie
Jak je uvedeno ve výše uvedených chybách prohlížeče, tato opakující se přesměrování mohou být způsobena také soubory cookie v prohlížeči, které ukládají stará přesměrování do mezipaměti. Prvním krokem při testování by bylo vymazání mezipaměti a souborů cookie v prohlížeči. Pokud jste již vymazali mezipaměť a soubory cookie v prohlížeči, pak je čas přejít k pokročilejšímu odstraňování problémů.
Použití vývojářských nástrojů pro přesměrovací smyčky
Dalším krokem při odstraňování problémů s těmito druhy smyček přesměrování je použití nástrojů pro vývojáře ve Firefoxu nebo Chrome. Tyto nástroje se běžně otevírají stisknutím klávesy F12. Ujistěte se, že jste vybrali Síť kartu v některém z nich a poté znovu načtěte stránku, se kterou máte problém.
Po opětovném načtení stránky by se vám v novém okně měla zobrazit řada přesměrování. Při pohledu na přesměrování můžete zjistit, zda přesměrovávají mezi několika různými věcmi nebo přesměrovávají na stejnou věc. V obou případech můžete vidět kroky, které vedou k chybě, nikoli pouze chybu prohlížeče koncového uživatele.
Nástroje pro vývojáře ve Firefoxu
Použití cURL pro přesměrovací smyčky
V rámci psaní tohoto článku jsme dali dohromady poměrně jednoduchý Bash skript, který lze použít na jakémkoli unixovém systému s curl příkaz. Použití curl je hezké, protože neukládá věci do mezipaměti stejným způsobem jako prohlížeče, takže vám někdy může poskytnout jiný pohled na řešení problémů.
Zkopírujte následující text do svého preferovaného textového editoru a uložte jej 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
donePoté označte redirects.sh soubor jako spustitelný.
chmod +x redirects.shNáš skript můžete spustit, stejně jako příklady níže, přidáním vaší domény za název skriptu. Dokáže dokonce zkontrolovat více domén a bude kontrolovat přesměrování každé adresy URL, přičemž umístí záhlaví mezi samostatné testované domény.
Ukázkový výstup
./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 OKPříklad nekonečného přesměrování 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/Postranní poznámka k typům přesměrování
Při pohledu na kudrlinku Na výstupu výše můžete vidět, že kód odpovědi HTTP je 301. Přesměrování 301 jsou „Trvalé“ přesměrování, což znamená, že se něco trvale přesunulo a vy nebo váš prohlížeč to musíte nyní i v budoucnu vyhledat v novém umístění. Přesměrování 302 jsou „dočasná“ přesměrování, což znamená, že se něco prozatím přesunulo, ale nemusí být vždy na novém místě.
Přesměrování 301 jsou častěji zapsána jako položky přesměrování nebo přepisu v souboru .htaccess. Přesměrování 302, ať už záměrně nebo podle konvence, jsou však často generována v kódu webové stránky. Takže dobrým pravidlem je, že 301 jsou v souborech .htaccess a 302 jsou v kódu webu. Nemusí to být vždy pravda, ale je dobré to mít na paměti.
Přesměrování v souboru .htaccess
Soubor .htaccess je konfigurační soubor používaný k úpravě chování serveru Apache podle adresáře na webu/serveru. Toto je konfigurační soubor na uživatelské úrovni a lze zde upravovat pouze některé konfigurace Apache, ačkoli přesměrování se běžně používají.
Můžete mít více souborů .htaccess, které kaskádovitě přecházejí přes řadu adresářů. Pokud máte .htaccess v nadřazeném adresáři a další v podadresáři, oba ovlivní podadresář. V těchto případech je důležité si pamatovat, kde máte a kde nemáte soubory .htaccess, abyste předešli konfliktům mezi soubory .htaccess na různých úrovních.
Níže je uvedena řada příkladů přesměrování, které vám pomohou identifikovat přesměrování ve vašem souboru .htaccess. Toto nejsou jediné způsoby, jak provádět tyto druhy přesměrování, ale měly by vám ukázat, jak vypadají nejběžnější přesměrování, abyste je mohli rozpoznat, pokud jsou v souboru .htaccess, se kterým pracujete.
Vynutit HTTPS
Níže uvedený .htaccess kód nejprve zkontroluje, zda požadavek přišel na server pomocí HTTP nebo HTTPS. Pokud požadavek nepoužil HTTPS, konfigurace sdělí prohlížeči, aby přesměroval na HTTPS verzi stejného webu a URL, které byly požadovány dříve.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Vynutit HTTPS:Když je za Load Balancerem nebo proxy (CloudFlare/Incapsula/Sucuri/atd.)
Někdy můžete používat proxy, jako je load balancer nebo webový firewall, jako CloudFlare, Incapsula nebo Sucuri. Ty lze nakonfigurovat tak, aby používaly SSL na frontendu, ale nepoužívaly SSL na backendu. Aby to fungovalo správně, musíte zkontrolovat nejen HTTPS v požadavku, ale také to, zda proxy předal původní požadavek HTTPS serveru pouze pomocí HTTP. Toto následující pravidlo kontroluje, zda byl požadavek předán z HTTPS, a pokud ano, nepokusí se přesměrovat další čas.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Vynutit jiné než www
Toto přesměrování pouze zkontroluje, zda byl název webu požadován s www na začátku názvu domény. Pokud je zahrnuto www, přepíše požadavek a řekne prohlížeči, aby přesměroval na verzi bez www názvu domény.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Vynutit www
Toto poslední přesměrování zkontroluje, zda název webu nebyl požadován s www na začátku názvu domény. Pokud www není zahrnuto, přepíše požadavek a řekne prohlížeči, aby přesměroval na www verzi domény.
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]WordPress
WordPress CMS používá soubor .htaccess pro přepisování adres URL na index.php soubor, ale definuje URL webové stránky jako hodnotu v databázi. Pokud ještě neznáte název databáze, která je na webu používána, můžete si jej vyhledat v hlavní konfiguraci pro WordPress (wp-config.php ).
Můžete také otevřít soubor v textovém editoru a vyhledat tyto hodnoty, ale z připojení SSH můžete použít program grep . Tím získáte více než jen název databáze, ale název databáze je nejdůležitější pro to, co musíme udělat dále.
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', '');Tabulka wp_options
Jakmile znáte název databáze, můžete se podívat na tabulku možností databáze Wordpress a zjistit, na jaké URL je v databázi nastaveno. Tabulka voleb může mít na začátku názvu tabulky libovolnou předponu, ale často je to "wp_" ve výchozím nastavení, takže úplný název tabulky voleb je obvykle wp_options . Dvě linie, které jsou důležité, jsou domov a siteurl řádky v tabulce možností. Můžete je najít pomocí phpMyAdmin , nebo jiný nástroj pro správu databází, ale z příkazového řádku můžete také spustit následující mysql příkaz.
mysql -e 'show tables' wordpress_database | grep options
prefix_optionsKontrola nakonfigurované adresy URL
Z příkazového řádku můžete zkontrolovat, jaké jsou aktuální hodnoty domů a siteurl řádky v tabulce možností. Příkaz by vám měl poslat a vypsat jako v příkladu níže. Důležité je, že se za většiny okolností shodují a jsou to, co očekáváte. Pokud nejsou takové, jaké očekáváte, budete je chtít odpovídajícím způsobem aktualizovat.
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 |
+-----------+-------------+----------------------------------+----------+Aktualizace nakonfigurované adresy URL
Následující příkaz aktualizuje dva řádky wp_options tabulky pro danou databázi na novou URL. Tento příkaz by měl vyhovovat většině situací, kdy potřebujete aktualizovat nebo opravit adresu URL nakonfigurovanou pro web ve Wordpressu. Aktualizace base_urls nakonfigurován na Wordpress Multisite přesahuje rozsah tohoto článku, ale zahrnoval by aktualizaci více wp_option zadejte tabulky.
mysql -e 'update wp_options set option_value="https://www.example.com" where option_name rlike "home|siteurl"' wordpress_databaseMagento
Název databáze Magento je nakonfigurován v jednom z následujících souborů, local.xml nebo env.php . Můžete také nakonfigurovat předponu pro názvy tabulek databáze Magento, ale obvykle není nastavena. Očekávaný název hlavní konfigurační tabulky databáze je tedy pouze core_config_data .
# Version 1.x
app/etc/local.xml
# Version 2.x
app/etc/env.phpTabulka core_config_data
Existuje mnoho potenciálních adres URL, které lze konfigurovat, ale všechny mají "base_url "." jako součást řádku v databázi. Primární nakonfigurované adresy URL budou zabezpečené a nezabezpečené adresy URL, ale můžete také nastavit adresy URL pro obrázky, soubory motivů nebo dokonce nastavit samostatnou adresu URL pro oblast správy webu. Opět je můžete najít pomocí nástroje pro správu databází, ale z příkazového řádku můžete spustit něco jako následující.
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 |
+-----------+---------+----------+-----------------------+----------------------------+Chcete-li aktualizovat base_urls v databázi Magento byste spustili něco jako příkaz níže. Aktualizace base_urls Magento Multisite také přesahuje rozsah tohoto článku, ale zahrnovala by dodatečné odkazování na konkrétní scope_id hodnotu pro daný web nebo obchod nakonfigurovanou v databázi Magento.
mysql -e 'update core_config_data set value="https://www.example.com" where path rlike "web/.*/base_url"' magento_databaseVšechno to zabalit
S adresami URL nakonfigurovanými v databázi, jak je uvedeno výše, stojí za zmínku, že tyto CMS také poskytují své vlastní metody přesměrování v kódu webu. Pokud máte například přesměrování .htaccess, které přesměrovává na adresu URL, která se neshoduje s tím, co je v databázi, můžete skončit s nekonečnou smyčkou přesměrování, jak bylo popsáno výše. Nyní však víte, jak vypadají některá běžná přesměrování .htaccess a kde v některé databázi softwaru CMS najít nakonfigurované adresy URL. Jste také dobře vybaveni k testování, vyšetřování a potvrzování, zda tyto věci fungují ve shodě nebo fungují proti sobě, a k některým krokům k jejich vyřešení.