Отстраняване на неизправности:Твърде много пренасочвания

Грешката „твърде много пренасочвания“ означава, че уебсайтът продължава да бъде пренасочен между различни адреси по начин, който никога няма да завърши. Често това е резултат от конкуриращи се пренасочвания, като едно се опитва да наложи HTTPS (SSL), а друго пренасочва обратно към HTTP (не-SSL) или между www и не-www форми на URL адреса.

Ако използвате CMS като Wordpress, Magento и т.н., който използва base_url или конфигурация на тип URL в сайта, можете да завършите с конфигурацията в кода или базата данни, която е в конфликт с пренасочване във файл .htaccess. Тези конфликтни пренасочвания ще се въртят напред-назад и никога няма да завършат.

Вашият браузър ви предпазва от това, като позволява само определен брой пренасочвания (често десет или повече), преди да се откаже и да съобщи съобщението за грешка „твърде много пренасочвания“. Това се показва различно между Chrome, Firefox и други браузъри.

Firefox

Страницата не се пренасочва правилно. Възникна грешка по време на връзка с

Chrome

Тази страница не работи ви пренасочва твърде много пъти

Дори и тестовата програма curl се отказва след 50 пренасочвания по подразбиране.

Къдрица: Следвано максимален брой (X) пренасочвания

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

Първата стъпка:Кеш и бисквитки

Както е показано в грешките на браузъра по-горе, тези циклични пренасочвания могат да бъдат причинени и от бисквитки в браузъра, кеширащи стари пренасочвания. Първата стъпка в тестването би била да изчистите кеша и бисквитките във вашия браузър. Ако вече сте изчистили кеша и бисквитките в браузъра, тогава е време да преминете към по-разширено отстраняване на неизправности.

Използване на инструменти за разработчици за цикли за пренасочване

Следващата стъпка при отстраняване на неизправности от тези видове цикли на пренасочване е да използвате инструментите за разработчици във Firefox или Chrome. Тези инструменти обикновено се отварят с натискане на клавиша F12. Уверете се, че сте избрали Мрежата раздел в едно от тях и след това презаредете страницата, с която имате проблем.

След презареждане на страницата трябва да видите поредицата от пренасочвания, изброени за вас в новия прозорец. Разглеждайки пренасочванията, можете да видите дали те пренасочват между няколко различни неща или пренасочват към едно и също нещо. Така или иначе можете да видите стъпките, които водят до грешката, вместо само грешката в браузъра на крайния потребител.

Инструменти за програмисти във Firefox

Използване на cURL за цикли за пренасочване

Като част от написването на тази статия, ние съставихме доста прост Bash скрипт, който може да се използва във всяка подобна на Unix система с curl команда. Използването на curl е хубаво, защото не кешира нещата по същия начин, както браузърите, така че понякога може да ви даде различна гледна точка при отстраняване на неизправности.

Копирайте следното в предпочитания от вас текстов редактор и го запазете като 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

След това маркирайте redirects.sh файл като изпълним.

chmod +x redirects.sh

Можете да стартирате нашия скрипт, като примерите по-долу, като добавите своя домейн след името на скрипта. Той дори може да проверява множество домейни и ще проверява пренасочванията на всеки URL, на свой ред, поставяйки заглавка между отделни тествани домейни.

Примерен изход

./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

Пример за безкрайно пренасочване от HTTP към 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/

Странична бележка относно типовете пренасочване

Поглеждайки вкъдра изхода по-горе можете да видите, че кодът на HTTP отговор е 301. 301 пренасочванията са „Постоянно“ пренасочване, което означава, че нещо е преместено за постоянно и вие или вашият браузър трябва да го търсите на новото място както сега, така и в бъдеще. 302 пренасочвания са „временни“ пренасочвания, което означава, че нещо се е преместило засега, но може да не е винаги на новото място.

301 пренасочвания по-често се записват като записи за пренасочване или пренаписване във файл .htaccess. 302 пренасочвания обаче, или по дизайн, или по конвенция, често се генерират в кода на уебсайт. Така че добро правило е, че 301s са в .htaccess файлове, а 302s са в кода на сайта. Това може да не винаги е вярно, но е добре да имате предвид.

Пренасочвания във файла .htaccess

Файлът .htaccess е конфигурационен файл, използван за промяна на поведението на Apache сървъра на директория на уебсайт/сървър. Това е конфигурационен файл на ниво потребител и тук могат да се редактират само някои конфигурации на Apache, въпреки че пренасочванията са често използвани.

Можете да имате множество .htaccess файлове, които каскадират върху поредица от директории. Ако имате .htaccess в родителска директория и друг в поддиректория, и двете ще засегнат поддиректорията. В тези случаи е важно да запомните къде имате и къде нямате .htaccess файлове, за да предотвратите конфликти между .htaccess файлове на различни нива.

По-долу са дадени поредица от примери за пренасочване, които ще помогнат при идентифицирането на пренасочвания във вашия .htaccess файл. Това не са единствените начини за извършване на тези видове пренасочвания, но те трябва да ви покажат как изглеждат най-често срещаните пренасочвания, за да можете да ги разпознаете, ако са във файл .htaccess, с който работите.

Принудително HTTPS

Кодът .htaccess по-долу първо проверява дали заявката е постъпила в сървъра чрез HTTP или HTTPS. Ако заявката не използва HTTPS, тогава конфигурацията ще каже на браузъра да пренасочи към HTTPS версията на същия уебсайт и URL, които са били заявени преди.

RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Принудително HTTPS:Когато е зад Load Balancer или прокси (CloudFlare/Incapsula/Sucuri/и т.н.)

Понякога може да използвате прокси, като балансьор на натоварване или уеб защитна стена, като CloudFlare, Incapsula или Sucuri. Те могат да бъдат конфигурирани да използват SSL на предния край, но не и да използват SSL в задния край. За да позволите това да работи правилно, трябва да проверите не само за HTTPS в заявката, но и дали проксито е прехвърлило оригиналната HTTPS заявка към сървъра, използвайки само HTTP. Следното правило проверява дали заявката е била препратена от HTTPS и ако е така, не се опитва да пренасочва допълнително време.

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

Принудително не-www

Това пренасочване проверява само дали името на уебсайта е било поискано с www в началото на името на домейна. Ако www е включен, той пренаписва заявката и казва на браузъра да пренасочи към версията без www на името на домейна.

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

Принудително www

Това последно пренасочване проверява дали името на уебсайта не е било поискано с www в началото на името на домейна. Ако www не е включен, той пренаписва заявката и казва на браузъра да пренасочи към www версията на домейна.

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

WordPress

WordPress CMS използва файл .htaccess за пренаписване на URL адреси в index.php файл, но той дефинира URL адреса на уебсайта като стойност в базата данни. Ако все още не знаете името на базата данни, която се използва на сайта, можете да го потърсите в основната конфигурация за WordPress (wp-config.php ).

Можете също да отворите файла в текстов редактор и да потърсите тези стойности, но от SSH връзка можете да използвате програмата grep . Това ви дава повече от името на базата данни, но името на базата данни е най-важното за това, което трябва да направим по-нататък.

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

След като знаете името на базата данни, можете да погледнете таблицата с опции на базата данни на Wordpress, за да видите какво е зададен URL адресът в базата данни. Таблицата с опции може да има произволен префикс в началото на името на таблицата, но често е "wp_" по подразбиране, така че пълното име на таблицата с опции обикновено е wp_options . Двете линии, които са важни, са дом и siteurl редове в таблицата с опции. Можете да ги намерите с помощта на phpMyAdmin , или друга помощна програма за управление на база данни, но от командния ред можете просто да стартирате следния mysql команда.

mysql -e 'show tables' wordpress_database | grep options

prefix_options

Проверка на конфигурирания URL адрес

От командния ред можете да проверите какви са текущите стойности на home и siteurl редове в таблицата с опции. Командата трябва да ви изпрати и да изведе като примера по-долу. Важното е, че те съвпадат помежду си при повечето обстоятелства и че са това, което очаквате. Ако не са това, което очаквате, тогава ще искате да ги актуализирате съответно.

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

Актуализиране на конфигурирания URL адрес

Следната команда ще актуализира двата реда на wp_options таблица за дадена база данни към нов URL. Тази команда трябва да отговаря на повечето ситуации, в които трябва да актуализирате или коригирате URL адреса, конфигуриран за сайт на Wordpress. Актуализиране на base_urls конфигуриран в Wordpress Multisite е извън обхвата на тази статия, но ще включва актуализиране на множество wp_option тип таблици.

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

Magento

Името на базата данни на Magento е конфигурирано в един от следните файлове, local.xml или env.php . Можете също да конфигурирате префикс за имената на таблиците на базата данни на Magento, но той обикновено не е зададен. Така че очакваното име за основната конфигурационна таблица на базата данни е просто core_config_data .

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

# Version 2.x
 app/etc/env.php

Таблицата core_config_data

Има много потенциални URL адреси, които могат да бъдат конфигурирани, но всички те имат "base_url " като част от реда в базата данни. Основните конфигурирани URL адреси ще бъдат защитените и несигурните URL адреси, но можете също да настроите URL адреси за изображения, файлове с теми или дори да настроите отделен URL за административната област на сайта. Можете отново да ги намерите с помощта на помощна програма за управление на база данни, но от командния ред можете да изпълните нещо като следното.

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

За да актуализирате base_urls в базата данни на Magento ще изпълните нещо като командата по-долу. Актуализирането на base_urls на Magento Multisite също е извън обхвата на тази статия, но ще включва допълнително препращане към конкретния scope_id стойност за дадения уебсайт или магазин, конфигуриран в базата данни на Magento.

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

Обвивам всичко

С URL адреси, конфигурирани в базата данни, както е показано по-горе, заслужава да се отбележи, че тези CMS също предоставят свои собствени методи за пренасочване в кода на сайта. Ако, например, имате пренасочване .htaccess, което пренасочва към URL, който не е в съответствие с това, което е в базата данни, можете да завършите с безкрайния цикъл за пренасочване, както е описано по-рано. Сега обаче знаете как изглеждат някои често срещани пренасочвания на .htaccess и къде да намерите конфигурираните URL адреси в някои CMS софтуерни бази данни. Освен това сте добре подготвени да тествате, разследвате и потвърждавате дали тези неща работят съвместно или работят едно срещу друго, както и някои стъпки за разрешаването им.