Felet "för många omdirigeringar" betyder att webbplatsen hela tiden omdirigeras mellan olika adresser på ett sätt som aldrig kommer att slutföras. Ofta är detta resultatet av konkurrerande omdirigeringar, en försöker tvinga fram HTTPS (SSL) och en annan omdirigerar tillbaka till HTTP (icke-SSL), eller mellan www- och icke-www-former av webbadressen.
Om du använder ett CMS som Wordpress, Magento, etc., som använder en base_url eller URL-typkonfiguration inom webbplatsen, kan du sluta med att konfigurationen i koden eller databasen kommer i konflikt med en omdirigering i en .htaccess-fil. Dessa motstridiga omdirigeringar kommer att flip flop fram och tillbaka och aldrig slutföras.
Din webbläsare skyddar dig från detta genom att bara tillåta ett visst antal omdirigeringar (ofta tio eller så) innan den ger upp och rapporterar felmeddelandet "för många omdirigeringar". Detta visas på olika sätt för Chrome, Firefox och andra webbläsare.
Firefox
Sidan omdirigerar inte korrekt. Ett fel uppstod under en anslutning till
Chrome
Den här sidan fungerar inte
Även testverktyget curl ger upp efter 50 omdirigeringar som standard.
Curl: Maximalt (X) omdirigeringar följs
curl -svILk https://www.example.com
....
* Maximum (50) redirects followedDet första steget:Cache och cookies
Som visas i webbläsarfelen ovan kan dessa looping-omdirigeringar också orsakas av att cookies i webbläsaren cachar gamla omdirigeringar. Det första steget i testet skulle vara att rensa ditt cache och cookies i din webbläsare. Om du redan har rensat cacheminne och cookies i webbläsaren är det dags att gå vidare till lite mer avancerad felsökning.
Använda utvecklarverktyg för omdirigeringsslingor
Nästa steg i att felsöka den här typen av omdirigeringsslingor är att använda utvecklarverktygen i Firefox eller Chrome. Dessa verktyg öppnas vanligtvis genom att trycka på F12-tangenten. Se till att du väljer Nätverk fliken i någon av dessa och ladda sedan om sidan du har problem med.
När du har laddat om sidan bör du se serien av omdirigeringar listade åt dig i det nya fönstret. När du tittar på omdirigeringarna kan du se om de omdirigerar mellan några olika saker eller omdirigerar till samma sak. Hur som helst kan du se stegen som leder fram till felet, istället för bara slutanvändarens webbläsarfel.
Utvecklarverktyg i Firefox
Använda cURL för omdirigeringsslingor
Som en del av att skriva den här artikeln har vi satt ihop ett ganska enkelt Bash-skript som kan användas på alla Unix-liknande system med curl kommando. Att använda curl är trevligt, eftersom det inte cachelagrar saker på samma sätt som webbläsare gör, så det kan ibland ge dig ett annat perspektiv vid felsökning.
Kopiera följande till din föredragna textredigerare och spara den som 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
doneMarkera sedan redirects.sh fil som körbar.
chmod +x redirects.shDu kan köra vårt skript, som exemplen nedan, genom att lägga till din domän efter skriptnamnet. Det kan till och med kontrollera flera domäner och det kommer att kontrollera omdirigeringarna för varje webbadress, i sin tur och placera en rubrik mellan separata domäner som testas.
Exempel på utdata
./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 OKExempel på en oändlig omdirigering från HTTP till 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/En sidoanteckning om omdirigeringstyper
Tittar på krullen utdata ovan kan du se att HTTP-svarskoden är 301. 301-omdirigeringar är "permanenta" omdirigering, vilket betyder att något har flyttats permanent, och du eller din webbläsare måste leta upp det på den nya platsen både nu och i framtiden. 302-omdirigeringar är "Tillfälliga" omdirigeringar vilket betyder att något har flyttats för nu, men att det kanske inte alltid finns på den nya platsen.
301-omdirigeringar skrivs ofta ut som omdirigering eller omskrivningsposter i en .htaccess-fil. 302-omdirigeringar genereras dock ofta i koden för en webbplats, antingen genom design eller konvention. Så en bra tumregel är att 301:or finns i .htaccess-filer och 302:or finns i webbplatskod. Detta kanske inte alltid är sant, men det är bra att ha i åtanke.
Omdirigeringar i .htaccess-filen
.htaccess-filen är en konfigurationsfil som används för att ändra Apache-serverbeteende per katalog på en webbplats/server. Detta är en konfigurationsfil på användarnivå och endast vissa Apache-konfigurationer kan redigeras här, även om omdirigeringar är vanligt förekommande.
Du kan ha flera .htaccess-filer som överlappar en serie kataloger. Om du har en .htaccess i en överordnad katalog och en annan i en underkatalog kommer de båda att påverka underkatalogen. I dessa fall är det viktigt att komma ihåg var du har och inte har .htaccess-filer, för att förhindra konflikter mellan .htaccess-filer på olika nivåer.
Nedan finns en serie omdirigeringsexempel som hjälper dig att identifiera omdirigeringar i din .htaccess-fil. Det här är inte de enda sätten att göra den här typen av omdirigeringar, men dessa bör visa dig hur de vanligaste omdirigeringarna ser ut så att du kan känna igen dem om de finns i en .htaccess-fil som du arbetar med.
Tvinga fram HTTPS
.htaccess-koden nedan kontrollerar först om begäran kom till servern med HTTP eller HTTPS. Om begäran inte använde HTTPS, kommer konfigurationen att tala om för webbläsaren att omdirigera till HTTPS-versionen av samma webbplats och URL som efterfrågades tidigare.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Force HTTPS:When Behind a Load Balancer or Proxy (CloudFlare/Incapsula/Sucuri/etc.)
Ibland kanske du använder en proxy, som en lastbalanserare eller en webbbrandvägg, som CloudFlare, Incapsula eller Sucuri. Dessa kan konfigureras för att använda SSL på fronten, men inte använda SSL på baksidan. För att tillåta detta att fungera korrekt måste du inte bara kontrollera för HTTPS i begäran, utan också om proxyn skickade den ursprungliga HTTPS-förfrågan till servern med bara HTTP. Följande regel kontrollerar om begäran har vidarebefordrats från HTTPS och försöker i så fall inte omdirigera en extra gång.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Tvinga icke-www
Denna omdirigering kontrollerar bara om webbplatsens namn efterfrågades med www i början av domännamnet. Om www ingår, skriver den om begäran och uppmanar webbläsaren att omdirigera till den icke-www-version av domännamnet.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Tvinga www
Denna sista omdirigering kontrollerar om webbplatsens namn inte efterfrågades med www i början av domännamnet. Om www inte ingår, skriver den om begäran och ber webbläsaren att omdirigera till www-versionen av domänen.
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]WordPress
WordPress CMS använder en .htaccess-fil för att skriva om webbadresser till index.php fil, men den definierar webbadressen till webbplatsen som ett värde i databasen. Om du inte redan vet namnet på databasen som används på webbplatsen kan du slå upp den i huvudkonfigurationen för WordPress (wp-config.php ).
Du kan också öppna filen i en textredigerare och leta efter dessa värden, men från en SSH-anslutning kan du använda programmet grep . Detta ger dig mer än bara databasnamnet, men databasnamnet är det viktigaste för vad vi behöver göra härnäst.
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', '');Wp_options-tabellen
När du vet namnet på databasen kan du titta på alternativtabellen i Wordpress-databasen för att se vad webbadressen är inställd på i databasen. Alternativtabellen kan ha vilket prefix som helst i början av tabellnamnet, men det är ofta "wp_" som standard, så det fullständiga namnet på alternativtabellen är vanligtvis wp_options . De två linjerna som är viktiga är hemmet och siteurl rader i alternativtabellen. Du kan hitta dessa med phpMyAdmin , eller ett annat databashanteringsverktyg, men från kommandoraden kan du också bara köra följande mysql kommando.
mysql -e 'show tables' wordpress_database | grep options
prefix_optionsKontrollera den konfigurerade webbadressen
Från kommandoraden kan du kontrollera vilka de aktuella värdena för hem och siteurl rader i alternativtabellen. Kommandot ska skicka och mata ut som exemplet nedan. Det viktiga är att dessa matchar varandra under de flesta omständigheter och att de är vad du förväntar dig. Om de inte är vad du förväntar dig kommer du att vilja uppdatera dem därefter.
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 |
+-----------+-------------+----------------------------------+----------+Uppdatera den konfigurerade webbadressen
Följande kommando kommer att uppdatera de två raderna i wp_options tabell för en given databas till en ny URL. Detta kommando bör passa de flesta situationer där du behöver uppdatera eller korrigera URL:en som är konfigurerad för en Wordpress-webbplats. Uppdaterar base_urls konfigurerad i en Wordpress Multisite ligger utanför ramen för denna artikel, men skulle innebära uppdatering av flera wp_option typ tabeller.
mysql -e 'update wp_options set option_value="https://www.example.com" where option_name rlike "home|siteurl"' wordpress_databaseMagento
Magento-databasens namn är konfigurerat i en av följande filer, local.xml eller env.php . Du kan också konfigurera ett prefix för tabellnamnen för Magento-databasen, men det är vanligtvis inte inställt. Så det förväntade namnet för databasens huvudkonfigurationstabell är bara core_config_data .
# Version 1.x
app/etc/local.xml
# Version 2.x
app/etc/env.phpCore_config_data-tabellen
Det finns många potentiella webbadresser som kan konfigureras, men de har alla "base_url " som en del av raden i databasen. De primära URL:erna som konfigureras kommer att vara de säkra och osäkra URL:erna, men du kan också ställa in URL:er för bilder, temafiler eller till och med ställa in en separat URL för administrationsområdet för webbplatsen. Du kan återigen hitta dessa med hjälp av ett databashanteringsverktyg, men från kommandoraden kan du köra något i stil med följande.
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 |
+-----------+---------+----------+-----------------------+----------------------------+För att uppdatera base_urls i Magento-databasen skulle du köra något liknande kommandot nedan. Att uppdatera base_urls för en Magento Multisite ligger också utanför ramen för denna artikel, men skulle innebära att man dessutom hänvisar till det specifika scope_id värde för den givna webbplatsen eller butiken konfigurerad i Magento-databasen.
mysql -e 'update core_config_data set value="https://www.example.com" where path rlike "web/.*/base_url"' magento_databaseSlutar allt
Med URL:er konfigurerade i databasen, som visas ovan, är det värt att notera att dessa CMS:er också tillhandahåller sina egna omdirigeringsmetoder inom webbplatskoden. Om du till exempel har en .htaccess-omdirigering som omdirigerar till en URL som inte stämmer överens med det som finns i databasen, kan du sluta med den oändliga omdirigeringsslingan som beskrivits tidigare. Men du vet nu hur några vanliga .htaccess-omdirigeringar ser ut och var du kan hitta de konfigurerade webbadresserna i någon CMS-programvarudatabas. Du är också väl rustad för att testa, undersöka och bekräfta om dessa saker fungerar tillsammans eller mot varandra, och några steg för att lösa dem.