Database
 sql >> Datenbank >  >> RDS >> Database

Fehlerbehebung:Zu viele Weiterleitungen

Der Fehler "zu viele Weiterleitungen" bedeutet, dass die Website immer wieder zwischen verschiedenen Adressen umgeleitet wird, und zwar auf eine Weise, die niemals abgeschlossen wird. Dies ist häufig das Ergebnis konkurrierender Weiterleitungen, von denen eine versucht, HTTPS (SSL) zu erzwingen, und eine andere zurück zu HTTP (nicht-SSL) oder zwischen www- und nicht-www-Formen der URL umleitet.

Wenn Sie ein CMS wie Wordpress, Magento usw. verwenden, verwendet dieses eine base_url oder URL-Typ-Konfiguration innerhalb der Site, kann es passieren, dass die Konfiguration im Code oder in der Datenbank mit einer Weiterleitung in einer .htaccess-Datei in Konflikt steht. Diese widersprüchlichen Weiterleitungen wechseln hin und her und werden nie abgeschlossen.

Ihr Browser schützt Sie davor, indem er nur eine bestimmte Anzahl von Weiterleitungen (oft zehn oder so) zulässt, bevor er aufgibt und die Fehlermeldung „zu viele Weiterleitungen“ meldet. Dies wird in Chrome, Firefox und anderen Browsern unterschiedlich angezeigt.

Firefox

Die Seite leitet nicht richtig weiter. Während einer Verbindung zu ist ein Fehler aufgetreten

Chrom

Diese Seite funktioniert nicht hat Sie zu oft weitergeleitet

Sogar das Testprogramm curl gibt standardmäßig nach 50 Umleitungen auf.

Welle: Maximal (X) Weiterleitungen gefolgt 

curl -svILk https://www.example.com
 ....
 * Maximum (50) redirects followed

Der erste Schritt:Cache und Cookies

Wie in den obigen Browserfehlern gezeigt, können diese sich wiederholenden Weiterleitungen auch durch Cookies im Browser verursacht werden, die alte Weiterleitungen zwischenspeichern. Der erste Schritt beim Testen wäre, Ihren Cache und Ihre Cookies in Ihrem Browser zu löschen. Wenn Sie den Cache und die Cookies im Browser bereits gelöscht haben, ist es an der Zeit, mit der erweiterten Fehlerbehebung fortzufahren.

Entwicklertools für Umleitungsschleifen verwenden

Der nächste Schritt zur Fehlerbehebung bei solchen Umleitungsschleifen ist die Verwendung der Entwicklertools in Firefox oder Chrome. Diese Tools werden normalerweise durch Drücken der Taste F12 geöffnet. Stellen Sie sicher, dass Sie das Netzwerk auswählen Tab in einem dieser beiden und laden Sie dann die Seite, mit der Sie ein Problem haben, neu.

Nachdem Sie die Seite neu geladen haben, sollten Sie die Reihe von Weiterleitungen sehen, die für Sie in dem neuen Fenster aufgeführt sind. Wenn Sie sich die Umleitungen ansehen, können Sie sehen, ob sie zwischen ein paar verschiedenen Dingen umleiten oder auf dasselbe umleiten. In beiden Fällen können Sie die Schritte sehen, die zu dem Fehler geführt haben, anstatt nur den Browserfehler des Endbenutzers.

Entwicklertools in Firefox

CURL für Umleitungsschleifen verwenden

Als Teil des Schreibens dieses Artikels haben wir ein ziemlich einfaches Bash-Skript zusammengestellt, das auf jedem Unix-ähnlichen System mit curl verwendet werden kann Befehl. Die Verwendung von curl ist nett, da es Dinge nicht auf die gleiche Weise zwischenspeichert wie Browser, sodass es Ihnen bei der Fehlerbehebung manchmal eine andere Perspektive geben kann.

Kopieren Sie Folgendes in Ihren bevorzugten Texteditor und speichern Sie es als 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
 done

Markieren Sie dann die redirects.sh Datei als ausführbar.

chmod +x redirects.sh

Sie können unser Skript wie in den folgenden Beispielen ausführen, indem Sie Ihre Domain nach dem Skriptnamen hinzufügen. Es kann sogar mehrere Domains prüfen und die Weiterleitungen jeder URL prüfen, indem es einen Header zwischen getrennten getesteten Domains platziert.

Beispielausgabe 
./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 OK
Beispiel einer unendlichen Weiterleitung von HTTP zu 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/
Eine Randbemerkung zu Weiterleitungstypen

Blick auf die Locke Oben können Sie sehen, dass der HTTP-Antwortcode 301 lautet. 301-Weiterleitungen sind "permanente" Weiterleitungen, was bedeutet, dass etwas dauerhaft verschoben wurde und Sie oder Ihr Browser es jetzt und in Zukunft an der neuen Stelle nachschlagen müssen. 302-Weiterleitungen sind "temporäre" Weiterleitungen, was bedeutet, dass etwas vorerst verschoben wurde, sich aber möglicherweise nicht immer an der neuen Position befindet.

301-Redirects werden meistens als Redirect- oder Rewrite-Einträge in eine .htaccess-Datei geschrieben. 302-Weiterleitungen werden jedoch entweder konstruktionsbedingt oder konventionell oft innerhalb des Codes einer Website generiert. Eine gute Faustregel lautet also, dass 301er in .htaccess-Dateien und 302er im Site-Code enthalten sind. Dies mag nicht immer wahr sein, aber es ist gut, daran zu denken.

Weiterleitungen in der .htaccess-Datei

Die .htaccess-Datei ist eine Konfigurationsdatei, die verwendet wird, um das Verhalten des Apache-Servers pro Verzeichnis auf einer Website/einem Server zu ändern. Dies ist eine Konfigurationsdatei auf Benutzerebene, und nur einige Apache-Konfigurationen können hier bearbeitet werden, obwohl Weiterleitungen häufig verwendet werden.

Sie können mehrere .htaccess-Dateien haben, die über eine Reihe von Verzeichnissen kaskadieren. Wenn Sie eine .htaccess-Datei in einem übergeordneten Verzeichnis und eine andere in einem Unterverzeichnis haben, wirken sich beide auf das Unterverzeichnis aus. In diesen Fällen ist es wichtig, sich daran zu erinnern, wo Sie .htaccess-Dateien haben und wo nicht, um Konflikte zwischen .htaccess-Dateien auf verschiedenen Ebenen zu vermeiden.

Nachfolgend finden Sie eine Reihe von Weiterleitungsbeispielen, die Ihnen dabei helfen, Weiterleitungen in Ihrer .htaccess-Datei zu identifizieren. Dies sind nicht die einzigen Möglichkeiten, diese Art von Weiterleitungen durchzuführen, aber diese sollten Ihnen zeigen, wie die häufigsten Weiterleitungen aussehen, damit Sie sie erkennen können, wenn sie sich in einer .htaccess-Datei befinden, mit der Sie arbeiten.

HTTPS erzwingen

Der folgende .htaccess-Code prüft zunächst, ob die Anfrage über HTTP oder HTTPS beim Server einging. Wenn für die Anfrage kein HTTPS verwendet wurde, weist die Konfiguration den Browser an, auf die HTTPS-Version derselben Website und URL umzuleiten, die zuvor angefordert wurde.

RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
HTTPS erzwingen:Wenn hinter einem Load Balancer oder Proxy (CloudFlare/Incapsula/Sucuri/etc.)

Manchmal verwenden Sie möglicherweise einen Proxy wie einen Load Balancer oder eine Web-Firewall wie CloudFlare, Incapsula oder Sucuri. Diese können so konfiguriert werden, dass sie SSL am Front-End verwenden, aber kein SSL am Back-End. Damit dies korrekt funktioniert, müssen Sie nicht nur auf HTTPS in der Anfrage prüfen, sondern auch, ob der Proxy die ursprüngliche HTTPS-Anfrage nur mit HTTP an den Server weitergeleitet hat. Die folgende Regel prüft, ob die Anfrage von HTTPS weitergeleitet wurde, und versucht in diesem Fall nicht, ein weiteres Mal umzuleiten.

RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteCond %{HTTP:X-Forwarded-Proto} =http
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Nicht-www erzwingen

Diese Weiterleitung prüft nur, ob der Website-Name mit www am Anfang des Domain-Namens angefordert wurde. Wenn das www enthalten ist, schreibt es die Anfrage neu und weist den Browser an, auf die nicht-www-Version des Domainnamens umzuleiten.

RewriteEngine On
 RewriteCond %{HTTP_HOST} ^www\. [NC]
 RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Www erzwingen

Diese letzte Weiterleitung prüft, ob der Website-Name nicht mit www am Anfang des Domain-Namens angefordert wurde. Wenn das www nicht enthalten ist, schreibt es die Anfrage neu und weist den Browser an, auf die www-Version der Domain umzuleiten.

RewriteEngine On
 RewriteCond %{HTTP_HOST} !^www\. [NC]
 RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

WordPress

Das WordPress-CMS verwendet eine .htaccess-Datei zum Umschreiben von URLs in die index.php Datei, aber es definiert die URL der Website als Wert in der Datenbank. Wenn Sie den Namen der Datenbank, die auf der Website verwendet wird, noch nicht kennen, können Sie ihn in der Hauptkonfiguration für WordPress (wp-config.php) nachschlagen ).

Sie können die Datei auch in einem Texteditor öffnen und nach diesen Werten suchen, aber über eine SSH-Verbindung können Sie das Programm grep verwenden . Dies gibt Ihnen mehr als nur den Datenbanknamen, aber der Datenbankname ist der wichtigste für das, was wir als nächstes tun müssen.

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', '');
Die wp_options-Tabelle

Sobald Sie den Namen der Datenbank kennen, können Sie in der Optionstabelle der Wordpress-Datenbank nachsehen, wie die URL in der Datenbank eingestellt ist. Die Optionstabelle kann ein beliebiges Präfix am Anfang des Tabellennamens haben, aber es ist oft "wp_" standardmäßig, daher lautet der vollständige Name der Optionstabelle normalerweise wp_options . Die beiden wichtigen Zeilen sind home und siteurl Zeilen in der Optionstabelle. Sie finden diese mit phpMyAdmin , oder ein anderes Datenbankverwaltungsprogramm, aber von der Befehlszeile aus können Sie auch einfach das folgende mysql ausführen Befehl.

mysql -e 'show tables' wordpress_database | grep options

prefix_options
Überprüfen der konfigurierten URL

Von der Befehlszeile aus können Sie die aktuellen Werte der home überprüfen und siteurl Zeilen in der Optionstabelle. Der Befehl sollte Sie senden und wie im folgenden Beispiel ausgeben. Der wichtige Teil ist, dass diese unter den meisten Umständen übereinstimmen und Ihren Erwartungen entsprechen. Wenn sie nicht Ihren Erwartungen entsprechen, sollten Sie sie entsprechend aktualisieren.

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 |
 +-----------+-------------+----------------------------------+----------+

Aktualisieren der konfigurierten URL

Der folgende Befehl aktualisiert die beiden Zeilen der wp_options Tabelle für eine bestimmte Datenbank zu einer neuen URL. Dieser Befehl sollte für die meisten Situationen geeignet sein, in denen Sie die für eine WordPress-Site konfigurierte URL aktualisieren oder korrigieren müssen. Aktualisieren der base_urls in einer WordPress-Multisite konfiguriert ist, würde den Rahmen dieses Artikels sprengen, würde aber das Aktualisieren mehrerer wp_option erfordern Typtabellen.

mysql -e 'update wp_options set option_value="https://www.example.com" where option_name rlike "home|siteurl"' wordpress_database

Magento

Der Name der Magento-Datenbank wird in einer der folgenden Dateien konfiguriert, local.xml oder env.php . Sie können auch ein Präfix für die Tabellennamen der Magento-Datenbank konfigurieren, das jedoch normalerweise nicht festgelegt wird. Der erwartete Name für die Hauptkonfigurationstabelle der Datenbank ist also nur core_config_data .

# Version 1.x
 app/etc/local.xml

# Version 2.x
 app/etc/env.php
Die core_config_data-Tabelle

Es gibt viele mögliche URLs, die konfiguriert werden können, aber alle haben "base_url " als Teil der Zeile in der Datenbank. Die konfigurierten primären URLs sind die sicheren und unsicheren URLs, aber Sie können auch URLs für Bilder, Themendateien oder sogar eine separate URL für den Verwaltungsbereich der Website einrichten. Sie können diese wiederum mit einem Datenbankverwaltungsprogramm finden, aber von der Befehlszeile aus können Sie etwa Folgendes ausführen.

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   |
 +-----------+---------+----------+-----------------------+----------------------------+

Um die base_urls zu aktualisieren in der Magento-Datenbank würden Sie so etwas wie den folgenden Befehl ausführen. Das Aktualisieren der base_urls einer Magento-Multisite würde ebenfalls den Rahmen dieses Artikels sprengen, würde aber eine zusätzliche Bezugnahme auf die spezifische scope_id erfordern Wert für die angegebene Website oder den Shop, der in der Magento-Datenbank konfiguriert ist.

mysql -e 'update core_config_data set value="https://www.example.com" where path rlike "web/.*/base_url"' magento_database

Alles einpacken

Bei URLs, die wie oben gezeigt in der Datenbank konfiguriert sind, ist es erwähnenswert, dass diese CMS auch ihre eigenen Umleitungsmethoden innerhalb des Site-Codes bereitstellen. Wenn Sie beispielsweise eine .htaccess-Umleitung haben, die auf eine URL umleitet, die nicht mit dem übereinstimmt, was in der Datenbank vorhanden ist, können Sie wie zuvor beschrieben mit der endlosen Umleitungsschleife enden. Sie wissen jetzt jedoch, wie einige gängige .htaccess-Weiterleitungen aussehen und wo Sie die konfigurierten URLs in einigen CMS-Softwaredatenbanken finden. Sie sind auch gut gerüstet, um zu testen, zu untersuchen und zu bestätigen, ob diese Dinge zusammenwirken oder gegeneinander arbeiten, und einige Schritte zu ihrer Lösung zu finden.