Lỗi "quá nhiều chuyển hướng" có nghĩa là trang web tiếp tục được chuyển hướng giữa các địa chỉ khác nhau theo cách sẽ không bao giờ hoàn thành. Thông thường, đây là kết quả của các chuyển hướng cạnh tranh, một người cố gắng buộc HTTPS (SSL) và một người khác chuyển hướng trở lại HTTP (không phải SSL) hoặc giữa các dạng URL có www và không phải www.
Nếu bạn đang sử dụng CMS như Wordpress, Magento, v.v., sử dụng base_url hoặc cấu hình loại URL trong trang web, bạn có thể kết thúc với cấu hình trong mã hoặc cơ sở dữ liệu xung đột với chuyển hướng trong tệp .htaccess. Các chuyển hướng xung đột này sẽ lật đi lật lại và không bao giờ hoàn tất.
Trình duyệt của bạn bảo vệ bạn khỏi điều này bằng cách chỉ cho phép một số chuyển hướng nhất định (thường là mười chuyển hướng) trước khi từ bỏ và báo cáo thông báo lỗi "quá nhiều chuyển hướng." Điều này hiển thị khác nhau giữa Chrome, Firefox và các trình duyệt khác.
Firefox
Trang không chuyển hướng đúng cách. Đã xảy ra lỗi khi kết nối với
Chrome
Trang này không hoạt động
Ngay cả tiện ích thử nghiệm curl bỏ cuộc sau 50 lần chuyển hướng theo mặc định.
Cuộn tròn: Các chuyển hướng tối đa (X) được theo sau
curl -svILk https://www.example.com
....
* Maximum (50) redirects followedBước đầu tiên:Cache và Cookies
Như được hiển thị trong các lỗi trình duyệt ở trên, các chuyển hướng lặp lại này cũng có thể do cookie trong trình duyệt lưu vào bộ nhớ đệm các chuyển hướng cũ. Bước đầu tiên trong quá trình kiểm tra là xóa bộ nhớ cache và cookie trong trình duyệt của bạn. Nếu bạn đã xóa bộ nhớ cache và cookie trong trình duyệt, thì đã đến lúc chuyển sang một số khắc phục sự cố nâng cao hơn.
Sử dụng Công cụ dành cho nhà phát triển cho Vòng lặp chuyển hướng
Bước tiếp theo trong việc khắc phục sự cố các loại vòng lặp chuyển hướng này là sử dụng Công cụ dành cho nhà phát triển trong Firefox hoặc Chrome. Các công cụ này thường được mở bằng cách nhấn phím F12. Đảm bảo rằng bạn chọn Mạng vào một trong hai tab này và sau đó tải lại trang bạn đang gặp sự cố.
Sau khi tải lại trang, bạn sẽ thấy một loạt các chuyển hướng được liệt kê cho bạn trong cửa sổ mới. Nhìn vào các chuyển hướng, bạn có thể biết liệu chúng đang chuyển hướng giữa một vài thứ khác nhau hay đang chuyển hướng đến cùng một thứ. Dù bằng cách nào, bạn có thể thấy các bước dẫn đến lỗi, thay vì chỉ lỗi trình duyệt của người dùng cuối.
Công cụ dành cho nhà phát triển trong Firefox
Sử dụng cURL cho các vòng lặp chuyển hướng
Là một phần của bài viết này, chúng tôi tập hợp một tập lệnh Bash khá đơn giản có thể được sử dụng trên bất kỳ hệ thống giống Unix nào với curl yêu cầu. Sử dụng curl rất hay, vì nó không lưu vào bộ nhớ cache mọi thứ theo cách giống như các trình duyệt vẫn làm, vì vậy, đôi khi nó có thể cung cấp cho bạn một góc nhìn khác khi khắc phục sự cố.
Sao chép phần sau vào trình soạn thảo văn bản ưa thích của bạn và lưu nó dưới dạng 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
doneSau đó, đánh dấu redirects.sh tệp dưới dạng tệp thực thi.
chmod +x redirects.shBạn có thể chạy tập lệnh của chúng tôi, như các ví dụ bên dưới, bằng cách thêm miền của bạn sau tên tập lệnh. Nó thậm chí có thể kiểm tra nhiều miền và nó sẽ lần lượt kiểm tra chuyển hướng của từng URL, đặt tiêu đề giữa các miền riêng biệt được kiểm tra.
Đầu ra mẫu
./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 OKVí dụ về Chuyển hướng Vô hạn từ HTTP sang 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/Lưu ý phụ về các loại chuyển hướng
Nhìn vào cuộn tròn đầu ra ở trên, bạn có thể thấy rằng mã phản hồi HTTP là 301. Chuyển hướng 301 là chuyển hướng "Vĩnh viễn", có nghĩa là thứ gì đó đã di chuyển vĩnh viễn và bạn hoặc trình duyệt của bạn phải tìm kiếm nó ở vị trí mới cả bây giờ và trong tương lai. Chuyển hướng 302 là chuyển hướng "Tạm thời" có nghĩa là một thứ gì đó đã được di chuyển ngay bây giờ, nhưng có thể không phải lúc nào cũng ở vị trí mới.
Chuyển hướng 301 thường không được viết ra dưới dạng chuyển hướng hoặc ghi lại các mục trong tệp .htaccess. Tuy nhiên, chuyển hướng 302 theo thiết kế hoặc quy ước thường được tạo trong mã của một trang web. Vì vậy, nguyên tắc chung là 301 nằm trong tệp .htaccess và 302 nằm trong mã trang web. Điều này có thể không phải lúc nào cũng đúng, nhưng đó là một điều tốt cần ghi nhớ.
Chuyển hướng trong Tệp .htaccess
Tệp .htaccess là tệp cấu hình được sử dụng để sửa đổi hành vi của máy chủ Apache trên mỗi thư mục trên trang web / máy chủ. Đây là tệp cấu hình cấp người dùng và chỉ một số cấu hình Apache có thể được chỉnh sửa tại đây, mặc dù chuyển hướng được sử dụng phổ biến.
Bạn có thể có nhiều tệp .htaccess xếp tầng trên một loạt thư mục. Nếu bạn có .htaccess trong thư mục mẹ và một .htaccess khác trong thư mục con, cả hai đều sẽ ảnh hưởng đến thư mục con. Trong những trường hợp này, điều quan trọng là phải nhớ nơi bạn có và không có tệp .htaccess, để tránh xung đột giữa các tệp .htaccess ở các cấp độ khác nhau.
Dưới đây là một loạt các ví dụ về chuyển hướng và sẽ hỗ trợ xác định các chuyển hướng trong tệp .htaccess của bạn. Đây không phải là cách duy nhất để thực hiện các loại chuyển hướng này, nhưng chúng sẽ cho bạn thấy các chuyển hướng phổ biến nhất trông như thế nào để bạn có thể nhận ra chúng nếu chúng nằm trong tệp .htaccess mà bạn đang làm việc.
Buộc HTTPS
Trước tiên, mã .htaccess bên dưới sẽ kiểm tra xem yêu cầu có được gửi đến máy chủ bằng HTTP hoặc HTTPS hay không. Nếu yêu cầu không sử dụng HTTPS, thì cấu hình sẽ yêu cầu trình duyệt chuyển hướng sang phiên bản HTTPS của cùng một trang web và URL đã được yêu cầu trước đó.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Buộc HTTPS:Khi Phía sau Cân bằng Tải hoặc Proxy (CloudFlare / Incapsula / Sucuri / v.v.)
Đôi khi bạn có thể đang sử dụng proxy, như bộ cân bằng tải hoặc tường lửa web, như CloudFlare, Incapsula hoặc Sucuri. Chúng có thể được định cấu hình để sử dụng SSL trên giao diện người dùng, nhưng không sử dụng SSL trên giao diện người dùng. Để cho phép điều này hoạt động chính xác, bạn cần phải kiểm tra không chỉ HTTPS trong yêu cầu mà còn xem proxy có chuyển yêu cầu HTTPS ban đầu tới máy chủ chỉ bằng HTTP hay không. Quy tắc sau đây kiểm tra xem yêu cầu có được chuyển tiếp từ HTTPS hay không và nếu có, hãy thử chuyển hướng thêm một thời gian nữa.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Buộc không phải www
Chuyển hướng này chỉ kiểm tra xem tên trang web có được yêu cầu với www ở đầu tên miền hay không. Nếu www được bao gồm, nó sẽ ghi lại yêu cầu và yêu cầu trình duyệt chuyển hướng đến phiên bản không phải www của tên miền.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Buộc www
Lần chuyển hướng cuối cùng này sẽ kiểm tra xem tên trang web có được yêu cầu với www ở đầu tên miền hay không. Nếu www không được bao gồm, nó sẽ ghi lại yêu cầu và yêu cầu trình duyệt chuyển hướng đến phiên bản www của miền.
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]WordPress
CMS WordPress sử dụng tệp .htaccess để ghi lại URL vào index.php nhưng nó xác định URL của trang web như một giá trị trong cơ sở dữ liệu. Nếu bạn chưa biết tên của cơ sở dữ liệu đang được sử dụng trên trang web, bạn có thể tra cứu nó trong cấu hình chính cho WordPress ( wp-config.php ).
Bạn cũng có thể mở tệp trong trình soạn thảo văn bản và tìm kiếm các giá trị này, nhưng từ kết nối SSH, bạn có thể sử dụng chương trình grep . Điều này cung cấp cho bạn nhiều thứ không chỉ là tên cơ sở dữ liệu, mà tên cơ sở dữ liệu là quan trọng nhất cho những gì chúng ta cần làm tiếp theo.
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', '');Bảng wp_options
Khi bạn biết tên của cơ sở dữ liệu, sau đó bạn có thể xem bảng tùy chọn của cơ sở dữ liệu Wordpress để xem URL được đặt thành gì trong cơ sở dữ liệu. Bảng tùy chọn có thể có bất kỳ tiền tố nào ở đầu tên bảng, nhưng nó thường là "wp_" theo mặc định, vì vậy tên đầy đủ của bảng tùy chọn thường là wp_options . Hai dòng quan trọng là nhà và siteurl các dòng trong bảng tùy chọn. Bạn có thể tìm thấy những thứ này bằng cách sử dụng phpMyAdmin hoặc một tiện ích quản lý cơ sở dữ liệu khác, nhưng từ dòng lệnh, bạn cũng có thể chỉ chạy mysql sau lệnh.
mysql -e 'show tables' wordpress_database | grep options
prefix_optionsKiểm tra URL đã định cấu hình
Từ dòng lệnh, bạn có thể kiểm tra các giá trị hiện tại của home và siteurl các dòng trong bảng tùy chọn. Lệnh sẽ gửi cho bạn và xuất ra như ví dụ bên dưới. Phần quan trọng là chúng phù hợp với nhau trong hầu hết các trường hợp và chúng là những gì bạn mong đợi. Nếu chúng không phải là những gì bạn mong đợi thì bạn sẽ muốn cập nhật chúng cho phù hợp.
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 |
+-----------+-------------+----------------------------------+----------+Cập nhật URL đã định cấu hình
Lệnh sau sẽ cập nhật hai hàng của wp_options bảng cho một cơ sở dữ liệu nhất định đến một URL mới. Lệnh này sẽ phù hợp với hầu hết các trường hợp mà bạn cần cập nhật hoặc sửa URL được định cấu hình cho trang Wordpress. Đang cập nhật base_urls được định cấu hình trong Wordpress Multisite nằm ngoài phạm vi của bài viết này, nhưng sẽ liên quan đến việc cập nhật nhiều wp_option nhập bảng.
mysql -e 'update wp_options set option_value="https://www.example.com" where option_name rlike "home|siteurl"' wordpress_databaseMagento
Tên cơ sở dữ liệu Magento được định cấu hình trong một trong các tệp sau, local.xml hoặc env.php . Bạn cũng có thể định cấu hình tiền tố cho tên bảng của cơ sở dữ liệu Magento, nhưng nó thường không được đặt. Vì vậy, tên dự kiến cho bảng cấu hình chính của cơ sở dữ liệu chỉ là core_config_data .
# Version 1.x
app/etc/local.xml
# Version 2.x
app/etc/env.phpBảng core_config_data
Có nhiều URL tiềm năng có thể được định cấu hình, nhưng tất cả chúng đều có " base_url " như một phần của dòng trong cơ sở dữ liệu. Các URL chính được định cấu hình sẽ là các URL an toàn và không an toàn, nhưng bạn cũng có thể thiết lập URL cho hình ảnh, tệp chủ đề hoặc thậm chí thiết lập một URL riêng cho khu vực quản trị của trang web. Bạn có thể tìm thấy chúng một lần nữa bằng cách sử dụng tiện ích quản lý cơ sở dữ liệu, nhưng từ dòng lệnh, bạn có thể chạy một cái gì đó như sau.
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 |
+-----------+---------+----------+-----------------------+----------------------------+Để cập nhật base_urls trong cơ sở dữ liệu Magento, bạn sẽ chạy một cái gì đó giống như lệnh dưới đây. Việc cập nhật base_urls của Magento Multisite cũng nằm ngoài phạm vi của bài viết này, nhưng sẽ liên quan đến việc tham khảo thêm scope_id cụ thể giá trị cho trang web hoặc cửa hàng nhất định được định cấu hình trong cơ sở dữ liệu Magento.
mysql -e 'update core_config_data set value="https://www.example.com" where path rlike "web/.*/base_url"' magento_databaseTóm tắt tất cả
Với các URL được định cấu hình trong cơ sở dữ liệu, như được hiển thị ở trên, điều đáng chú ý là các CMS này cũng cung cấp các phương thức chuyển hướng riêng trong mã trang web. Ví dụ:nếu bạn có chuyển hướng .htaccess đang chuyển hướng đến một URL không phù hợp với những gì có trong cơ sở dữ liệu, bạn có thể kết thúc với vòng lặp chuyển hướng vô hạn như được mô tả trước đó. Tuy nhiên, bây giờ bạn đã biết một số chuyển hướng .htaccess phổ biến trông như thế nào và tìm URL được định cấu hình ở đâu trong một số cơ sở dữ liệu phần mềm CMS. Bạn cũng được trang bị tốt để kiểm tra, điều tra và xác nhận xem những điều này có hoạt động đồng thời hay hoạt động chống lại nhau hay không và một số bước để giải quyết chúng.
