logo
GeekFormat

Trình kiểm tra chuỗi chuyển hướng

Kiểm tra chuỗi chuyển hướng

Kiểm tra từng hop 301/302/307/308, nhận dạng vòng lặp, chuyển hướng xuyên miền và vấn đề hạ cấp HTTPS.

Khi bạn nhập một địa chỉ web vào trình duyệt, đằng sau hậu trường có thể đã xảy ra một loạt các bước nhảy bạn không thấy: HTTP→HTTPS, không phải www→www, tên miền cũ→tên miền mới, liên kết ngắn→liên kết dài… Mỗi bước chuyển hướng đều đang tiêu tốn thời gian, ảnh hưởng đến thứ hạng SEO, thậm chí có thể âm thầm hạ cấp HTTPS thành HTTP. Trình kiểm tra chuỗi chuyển hướng theo dõi đường dẫn nhảy đầy đủ của URL từng bước từ góc nhìn máy chủ, hiển thị mã trạng thái (301/302/303/307/308), tiêu đề Location và địa chỉ đích của mỗi bước, tự động phát hiện vòng lặp chuyển hướng, chuyển hướng xuyên miền, hạ cấp HTTPS và cắt chuỗi cũng như các vấn đề khác, giúp bạn phát hiện các mối nguy chuyển hướng ẩn trong quá trình di chuyển tên miền, triển khai HTTPS và tối ưu hóa SEO.

Đề xuất Liên quan

Trình phân tích HSTS

Kiểm Tra Chứng Chỉ SSL

Tra cứu Mã trạng thái HTTP

Kiểm tra HTTP Headers

URL Parser

Kiểm tra mạng trang web

Trường hợp sử dụng

  • Xác minh di chuyển tên miền: sau khi trang web chuyển từ tên miền cũ sang tên miền mới, xác nhận từng bước xem URL cũ có được chuyển hướng vĩnh viễn 301 đến địa chỉ mới đúng hay không, tránh mất lưu lượng do chuỗi nhảy và mã trạng thái sai
  • Kiểm tra triển khai HTTPS: xác nhận chuỗi chuyển hướng HTTP→HTTPS có phải là 301 một bước hay không, kiểm tra có tồn tại vòng lặp hạ cấp HTTP→HTTPS→HTTP hay không, xác minh cấu hình HSTS có hiệu lực hay không
  • Phát hiện trang đích liên kết ngắn: theo dõi đường dẫn nhảy đầy đủ của liên kết ngắn (t.cn/bit.ly, v.v.), liên kết UTM tiếp thị hoặc liên kết chia sẻ mạng xã hội, xác nhận trang đích cuối cùng có phải là địa chỉ mong đợi hay không, kiểm tra xem bước nhảy trung gian có chèn tham số theo dõi hoặc chuyển hướng độc hại hay không
  • Chuẩn hóa www và không phải www: kiểm tra xem tên miền www và tên miền gốc có đúng chuyển hướng 301 lẫn nhau đến phiên bản chuẩn hóa hay không, tránh vấn đề SEO nội dung lặp lại do chạy song song hai đường dẫn
  • Gỡ lỗi chuyển hướng vòng lặp: khi trình duyệt báo lỗi ERR_TOO_MANY_REDIRECTS, sử dụng công cụ để định vị chính xác nút xảy ra vòng lặp, phân biệt là lỗi cấu hình Nginx/Apache, xung đột quy tắc CDN hay do plugin WordPress gây ra
  • Gỡ lỗi CDN và proxy ngược: kiểm tra xung đột chuyển hướng trong kiến trúc đa lớp như Cloudflare, CDN Alibaba Cloud, proxy ngược Nginx, nhận dạng vấn đề quy tắc CDN và quy tắc nguồn站 nhảy lẫn nhau
  • Kiểm toán sức khỏe SEO: định kỳ kiểm tra độ dài chuỗi chuyển hướng của các trang cốt lõi của trang web, đánh giá ảnh hưởng của nhảy nhiều bước đến hiệu quả truyền PageRank, tối ưu hóa chuỗi nhảy quá dài
  • Đánh giá rủi ro chuyển hướng xuyên miền: phát hiện các trường hợp liên quan đến chuyển hướng xuyên miền như nhảy đăng nhập, gọi lại OAuth, nhảy thanh toán, xác nhận Cookie và Session có được truyền chính xác trong quá trình xuyên miền hay không
  • Cân bằng tải và xác minh đa hoạt động: kiểm tra chiến lược chuyển hướng trong trường hợp trung tâm dữ liệu đa hoạt động, cân bằng tải toàn cục GSLB, xác nhận người dùng các khu vực khác nhau được chuyển hướng đúng đến nút khả dụng gần nhất
  • Gỡ lỗi bộ nhớ đệm chuyển hướng: xác minh cài đặt tiêu đề Cache-Control và Expires của chuyển hướng vĩnh viễn 301 và chuyển hướng tạm thời 302, kiểm tra truy cập bất thường do bộ nhớ đệm trình duyệt quy tắc chuyển hướng cũ gây ra

Tính năng

  • Theo dõi hoàn chỉnh từng bước: theo dõi mỗi bước chuyển hướng từ góc nhìn máy chủ, hiển thị lần lượt URL gốc, mã trạng thái mỗi bước, văn bản trạng thái, tiêu đề phản hồi Location và đường dẫn nhảy đầy đủ, không bỏ sót bất kỳ nút trung gian nào
  • Hỗ trợ tất cả mã trạng thái: bao gồm năm mã trạng thái chuyển hướng tiêu chuẩn 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect, 308 Permanent Redirect, và ghi chú sự khác biệt ngữ nghĩa của từng mã trạng thái
  • Phát hiện vòng lặp chuyển hướng: tự động nhận dạng mô hình nhảy vòng lặp như A→B→A, đánh dấu vị trí nút cụ thể xảy ra vòng lặp và độ dài vòng lặp, định vị chính xác nguồn gốc lỗi ERR_TOO_MANY_REDIRECTS
  • Nhận dạng chuyển hướng xuyên miền: phát hiện thay đổi Host/Tên miền từng bước, đánh dấu nút chuyển hướng xuyên miền, cảnh báo rủi ro mất Cookie và vấn đề kiểm tra trước CORS
  • Cảnh báo hạ cấp HTTPS: thống kê số lượng nút HTTP (không phải HTTPS) trong chuỗi chuyển hướng, đánh dấu chuyển hướng hạ cấp HTTPS→HTTP, cảnh báo rủi ro bảo mật và tác động tiêu cực đến SEO
  • Bảo vệ cắt chuỗi: đặt giới hạn độ sâu nhảy tối đa (20 bước), khi chuỗi quá dài sẽ tự động cắt và đánh dấu, tránh yêu cầu hết thời gian do theo dõi vô hạn
  • Tóm tắt thống kê nhảy: cung cấp tổng quan các chỉ số quan trọng như tổng số lần nhảy, URL đích cuối cùng, có phát hiện vòng lặp hay không, có xuyên miền hay không, số lượng nút HTTP, chuỗi có bị cắt hay không
  • Đánh giá tác động SEO: tự động đánh giá mức độ ảnh hưởng đến truyền PageRank và Core Web Vitals dựa trên số lần nhảy, loại mã trạng thái, tình trạng bao phủ HTTPS
  • URL kiểm thử đặt trước: tích hợp các địa chỉ kiểm thử phổ biến như geekformat.com, github.com, httpbin.org/redirect, dịch vụ liên kết ngắn, điền nhanh một cú nhấp để trải nghiệm
  • Lịch sử truy vấn gần đây: tự động lưu 8 bản ghi truy vấn gần nhất (lưu trữ cục bộ trong trình duyệt), hỗ trợ lặp lại phát hiện một cú nhấp, thuận tiện cho so sánh hiệu quả trước và sau sửa chữa
  • Thẻ đề xuất chẩn đoán:针对 các vấn đề được phát hiện như vòng lặp chuyển hướng, chuyển hướng xuyên miền, hạ cấp HTTP, chuỗi quá dài, đưa ra đề xuất sửa chữa cụ thể và hướng dẫn thực hành tốt nhất
  • Chế độ xem kép chi tiết và tóm tắt: mặc định hiển thị thẻ tóm tắt chuỗi, mở rộng có thể xem URL yêu cầu đầy đủ của mỗi bước, trạng thái phản hồi, đích Location và đánh dấu HTTPS

Cách Sử dụng

  1. Điền URL cần phát hiện vào ô nhập liệu (phải chứa tiền tố giao thức http:// hoặc https://), hoặc nhấp nút URL đặt trước (geekformat.com/github.com/httpbin.org/redirect, v.v.) để điền nhanh địa chỉ kiểm thử
  2. Nhấp nút「theo dõi chuỗi chuyển hướng」, công cụ sẽ gửi yêu cầu từ phía máy chủ, theo dõi từng bước theo tiêu đề phản hồi Location để ghi lại thông tin đầy đủ của mỗi bước nhảy
  3. Xem thẻ tóm tắt nhảy ở đầu trang: tổng số lần nhảy, URL đích cuối cùng, có phát hiện vòng lặp hay không, có tồn tại chuyển hướng xuyên miền hay không, số lượng nút HTTP, chuỗi có bị cắt do số bước nhảy quá nhiều hay không
  4. Trong khu vực trực quan hóa chuỗi xem thông tin chi tiết của mỗi bước nhảy: số thứ tự, URL yêu cầu, mã trạng thái phản hồi và văn bản mô tả, URL đích trong tiêu đề phản hồi Location, đánh dấu an toàn HTTPS
  5. Chú ý thẻ cảnh báo chẩn đoán: nếu phát hiện vòng lặp chuyển hướng (màu đỏ), hạ cấp HTTPS (màu cam), chuyển hướng xuyên miền (màu vàng) hoặc chuỗi quá dài (màu vàng), công cụ sẽ đánh dấu nổi bật tại vị trí tương ứng và cung cấp giải thích vấn đề
  6. Sử dụng khu vực đánh giá tác động SEO để xem mức độ ảnh hưởng của chuỗi chuyển hướng hiện tại đối với hiệu quả truyền PageRank, tốc độ tải trang và Core Web Vitals cũng như đề xuất tối ưu hóa
  7. Sau khi phát hiện xong có thể từ lịch sử truy vấn gần đây nhấp bất kỳ bản ghi nào để lặp lại phát hiện nhanh, so sánh thay đổi chuỗi nhảy trước và sau sửa chữa; cũng có thể chụp ảnh kết quả phát hiện hoặc sao chép văn bản để sử dụng cho giao tiếp nhóm và ghi nhận phiếu công việc

Câu hỏi Thường gặp

Chuỗi chuyển hướng vượt quá bao nhiêu bước được coi là quá nhiều? Có ảnh hưởng gì đến SEO?

Google chính thức khuyến nghị kiểm soát chuỗi chuyển hướng ở một bước, tối đa không quá 3 bước. Theo tài liệu của Google Search Central, Googlebot thường tuân theo tối đa 5 bước nhảy chuyển hướng sau đó ngừng theo dõi, nhưng điều này không có nghĩa là 5 bước là an toàn. Mỗi bước chuyển hướng đều sẽ tăng độ trễ tải trang (100-300ms/bước), lãng phí ngân sách thu thập, và có thể dẫn đến suy giảm truyền PageRank. 1 bước hầu như không có ảnh hưởng SEO; 2 bước có thể chấp nhận nhưng khuyến nghị tối ưu; hơn 3 bước bắt đầu ảnh hưởng đến LCP và hiệu quả thu thập; hơn 5 bước có rủi ro trang không được thu thập và lập chỉ mục. Sử dụng công cụ này kiểm tra chuỗi nhảy các trang cốt lõi của bạn, đảm bảo các URL quan trọng (trang chủ, trang sản phẩm cốt lõi, trang nội bộ lưu lượng cao) đều là một bước nhảy đến trực tiếp.

Chuyển hướng 301 có gây hại cho SEO không? PageRank có thể truyền đầy đủ không?

Chuyển hướng vĩnh viễn 301 được sử dụng đúng cách sẽ không gây hại cho SEO. Gary Illyes và John Mueller của Google đã nhiều lần xác nhận, chuyển hướng 301 từ tên miền HTTP di chuyển đến tên miền HTTPS, cũng như di chuyển vĩnh viễn trang trong cùng một tên miền, việc truyền PageRank là 100%, không có tổn thất. Nhưng cần lưu ý: 1) Chuyển hướng tạm thời 302 không truyền PageRank (hoặc hiệu quả truyền cực kỳ thấp); 2) Nếu trong chuỗi chuyển hướng xuất hiện noindex, chặn robots.txt, lỗi 4xx/5xx, việc truyền trọng số sẽ bị gián đoạn; 3) Sau khi di chuyển xuyên miền 301, cần gửi thông báo thay đổi tên miền trong Google Search Console để đẩy nhanh quá trình di chuyển chỉ mục; 4) 301 sẽ được trình duyệt bộ nhớ đệm dài hạn, giai đoạn kiểm thử khuyến nghị trước tiên dùng 302 xác nhận sau đó mới đổi thành 301.

Tại sao trang web của tôi tự động nhảy đến HTTP thay vì HTTPS? Làm sao để sửa chữa?

Chuyển hướng hạ cấp HTTPS→HTTP thường do các nguyên nhân sau: 1) Proxy ngược/CDN quay nguồn bằng HTTP, Nginx/Apache nguồn站 sử dụng biến $scheme để lấy giao thức thì nhận được là http chứ không phải https; 2) Trong mã lớp ứng dụng đã mã hóa cứng URL với tiền tố http://; 3) Home URL hoặc Site URL của các CMS như WordPress được đặt là http; 4) Trong .htaccess tồn tại dư quy tắc HTTP cũ; 5) Cài đặt SSL/TLS của dịch vụ bên thứ ba (CDN/WAF) là chế độ「linh hoạt」chứ không phải「nghiêm ngặt」. Các bước sửa chữa: trước tiên dùng công cụ này xác định hạ cấp xảy ra ở bước nào; Đặt SSL của CDN thành chế độ「Full (strict)」; Trong Nginx xử lý đúng tiêu đề X-Forwarded-Proto; WordPress thêm $_SERVER['HTTPS']='on'; vào wp-config.php; Triển khai tiêu đề phản hồi HSTS ngăn chặn hạ cấp ở mức trình duyệt; Kiểm tra tất cả quy tắc chuyển hướng đảm bảo mục tiêu là https://.

Làm sao để sửa chữa vòng lặp chuyển hướng trong Nginx (ERR_TOO_MANY_REDIRECTS)?

Hơn 90% vòng lặp chuyển hướng Nginx là do tiêu đề X-Forwarded-Proto không được xử lý đúng trong trường hợp proxy ngược/CDN. Phương pháp sửa chữa: 1) Đảm bảo CDN/cân bằng tải gửi tiêu đề X-Forwarded-Proto về phía后端: proxy_set_header X-Forwarded-Proto $scheme; 2) Nginx khi phán đoán sử dụng X-Forwarded-Proto thay vì $scheme để quyết định có nhảy HTTPS hay không. Khuyến nghị sử dụng khối map: map $http_x_forwarded_proto $is_https { default 0; "https" 1; } server { listen 80; if ($is_https = 0) { return 301 https://$host$request_uri; } } 3) Tránh viết quy tắc rewrite trong khối server kết nối vô hạn với chính nó; 4) Chuyển hướng www và không phải www chỉ cấu hình nhảy một chiều trong một khối server, đừng cấu hình hai chiều.

Làm sao để sửa chữa vòng lặp chuyển hướng trong Apache .htaccess?

Vòng lặp .htaccess của Apache thường do xung đột quy tắc RewriteRule gây ra. Các bước sửa chữa: 1) Đảm bảo RewriteEngine On chỉ xuất hiện một lần; 2) Quy tắc chuyển hướng HTTP→HTTPS đặt ở đầu tất cả các quy tắc, sử dụng: RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]; 3) Quy tắc www/không phải www đặt sau chuyển hướng HTTPS, và chỉ thực hiện nhảy một chiều (không phải www→www hoặc ngược lại); 4) Lưu ý ý nghĩa của cờ [L] là「last」nhưng nếu quy tắc đã sửa đổi URL thì sẽ bắt đầu đối sánh lại từ dòng đầu tiên, có thể dẫn đến vòng lặp, quy tắc phức tạp cân nhắc sử dụng cờ [END] (Apache 2.3.9+); 5) Kiểm tra xem có nhiều tệp .htaccess không (tệp .htaccess trong thư mục con cũng sẽ có hiệu lực); 6) Tạm thời đổi R=301 thành R=302 để kiểm thử, tránh sự can thiệp của bộ nhớ đệm trình duyệt.

Làm sao để sửa chữa vòng lặp chuyển hướng do Cloudflare gây ra?

Nguyên nhân phổ biến nhất của vòng lặp Cloudflare là cài đặt chế độ mã hóa SSL/TLS sai hoặc xung đột quy tắc trang: 1) Đổi chế độ SSL/TLS của Cloudflare từ「Flexible」thành「Full」hoặc「Full (strict)」— ở chế độ Flexible Cloudflare đến nguồn站 dùng HTTP, nếu nguồn站 đã cấu hình chuyển hướng bắt buộc HTTPS sẽ tạo thành vòng lặp; 2) Kiểm tra「Always Use HTTPS」trong「Edge Certificates」của Cloudflare có bật hay không, đừng đồng thời cấu hình chuyển hướng HTTPS ở cả nguồn站 và Cloudflare; 3) Kiểm tra xem trong Page Rules có quy tắc chuyển tiếp xung đột với nhau hay không; 4) Nếu sử dụng plugin WordPress của Cloudflare, đừng đồng thời cấu hình chuyển hướng HTTPS ở cả plugin và Cloudflare; 5) Kiểm tra quy tắc Forwarding URL có trỏ đến địa chỉ又被 Cloudflare chuyển hướng hay không.

Chuyển hướng 301, 302, 307, 308 có gì khác biệt? Nên chọn cái nào?

Sự khác biệt cốt lõi ở hai chiều「có vĩnh viễn hay không」và「có giữ lại phương thức yêu cầu hay không」. Hướng dẫn chọn nhanh: đối với yêu cầu GET trang thông thường (người dùng truy cập trang) — di chuyển vĩnh viễn dùng 301 (di chuyển tên miền, chuyển đổi HTTPS, thay đổi vĩnh viễn URL), nhảy tạm thời dùng 302 (kiểm thử A/B, bảo trì tạm thời, nhảy đăng nhập); đối với yêu cầu POST/PUT/DELETE (gọi API, gửi biểu mẫu) — di chuyển vĩnh viễn dùng 308, nhảy tạm thời dùng 307, đảm bảo phương thức yêu cầu và nội dung yêu cầu không bị mất; 303 chuyên dùng cho sau khi gửi biểu mẫu POST nhảy đến trang kết quả (bắt buộc GET, ngăn chặn gửi lại). Ghi nhớ đơn giản: 301=vĩnh viễn an toàn GET, 302=tạm thời an toàn GET, 307=tạm thời toàn phương thức, 308=vĩnh viễn toàn phương thức, 303=sau POST nhảy trang kết quả.

Trình duyệt có bộ nhớ đệm vĩnh viễn chuyển hướng 301 không? Làm sao để xóa bộ nhớ đệm 301?

Chuyển hướng vĩnh viễn 301 mặc định sẽ được trình duyệt bộ nhớ đệm, nhưng thời gian bộ nhớ đệm phụ thuộc vào cài đặt Cache-Control và Expires trong tiêu đề phản hồi. Nếu không chỉ định rõ tiêu đề bộ nhớ đệm, hành vi bộ nhớ đệm mặc định của các trình duyệt khác nhau: Chrome thường bộ nhớ đệm chuyển hướng 301 vài tuần đến vài tháng (thậm chí sau khi khởi động lại trình duyệt vẫn có thể bộ nhớ đệm); Firefox mặc định bộ nhớ đệm 301 nhưng sau khi khởi động lại trình duyệt có thể xác minh lại; Chiến lược bộ nhớ đệm của Safari tương đối thận trọng. Cách xóa bộ nhớ đệm 301: 1) Chrome: cài đặt→quyền riêng tư và bảo mật→xóa dữ liệu duyệt web→phạm vi thời gian chọn「tất cả thời gian」→chọn「ảnh và tệp được lưu trong bộ nhớ đệm」→xóa dữ liệu; 2) Khi công cụ phát triển (F12) đang mở thì chọn「Disable cache」của bảng Mạng; 3) Thêm tham số truy vấn vô nghĩa sau URL (?nocache=1) để bỏ qua bộ nhớ đệm; 4) Nhà phát triển Chrome có thể Flush sockets trong chrome://net-internals/#sockets, hoặc Clear host cache trong chrome://net-internals/#dns; 5) Giai đoạn kiểm thử sử dụng chuyển hướng tạm thời 302 thay vì 301, sau khi xác nhận không lỗi mới đổi thành 301.

Meta Refresh và chuyển hướng HTTP có gì khác biệt? Cái nào tốt hơn?

Meta Refresh là chuyển hướng được thực hiện bằng thẻ <meta> trong tài liệu HTML (như <meta http-equiv="refresh" content="0;url=https://example.com/new">), thực hiện nhảy sau khi trình duyệt phân tích HTML, trong khi chuyển hướng HTTP thông qua mã trạng thái 3xx ở cấp độ giao thức HTTP được máy chủ chỉ định trực tiếp nhảy. So sánh sự khác biệt: 1) Tốc độ: chuyển hướng HTTP bắt đầu nhảy ngay khi nhận được tiêu đề phản hồi, Meta Refresh cần chờ HTML tải xuống và phân tích xong mới nhảy, tốc độ chậm hơn; 2) SEO: Google thường có thể nhận dạng Meta Refresh và truyền trọng số (nếu delay=0), nhưng官方 khuyến nghị sử dụng chuyển hướng HTTP 301/302, vì Meta Refresh là nhảy phía client, tín hiệu không rõ ràng bằng chuyển hướng phía máy chủ; 3) Độ trễ: Meta Refresh có thể đặt thời gian trễ (như content="5;url=..." nghĩa là 5 giây sau mới nhảy), còn chuyển hướng HTTP không có chức năng này; 4) Khả năng truy cập: W3C không khuyến nghị sử dụng Meta Refresh, vì công nghệ hỗ trợ như trình đọc màn hình xử lý không tốt, cũng có thể làm người dùng bối rối; 5) Nút quay lại: Meta Refresh trong một số trình duyệt có thể phá vỡ hành vi nút quay lại. Kết luận: luôn ưu tiên sử dụng chuyển hướng HTTP 301/302/307/308, tránh sử dụng Meta Refresh, trừ khi bạn không thể kiểm soát cấu hình máy chủ (như được lưu trữ trên nền tảng trang tĩnh không thể cấu hình quy tắc phía máy chủ).

Chuyển hướng có ảnh hưởng đến LCP trong Core Web Vitals không?

Có, và ảnh hưởng rất lớn. Chuyển hướng xảy ra trước khi trình duyệt lấy tài liệu HTML, điều này có nghĩa là mỗi bước chuyển hướng đều sẽ trì hoãn thời gian bắt đầu tải tài liệu HTML. Điểm bắt đầu tính toán của LCP (Largest Contentful Paint, bản vẽ nội dung lớn nhất) là thời gian bắt đầu điều hướng, và trình duyệt phải nhận được HTML cuối cùng mới có thể bắt đầu phân tích DOM, tải CSS và kết xuất phần tử LCP. Giả sử mỗi bước chuyển hướng tăng 150ms độ trễ mạng (DNS+TCP+TLS+yêu cầu phản hồi), 3 bước chuyển hướng sẽ làm LCP tăng ít nhất 450ms, điều này đủ để đẩy LCP từ「tốt」(≤2,5s) sang khoảng「cần cải thiện」(2,5-4s). Tài liệu Core Web Vitals của Google rõ ràng đưa「tránh nhiều lần chuyển hướng」là một trong những đề xuất quan trọng để tối ưu hóa LCP. Thực hành tốt nhất: đảm bảo các trang cốt lõi không có chuyển hướng (liên kết trực tiếp đến URL cuối cùng), các chuyển hướng cần thiết như HTTP→HTTPS và chuẩn hóa www được kiểm soát ở một bước.

Làm sao để kiểm tra một liên kết ngắn cuối cùng nhảy đến đâu?

Liên kết ngắn (t.cn、bit.ly、dwz.cn、url.cn, v.v.) thường thông qua 1-3 bước chuyển hướng để đến URL cuối cùng,中间 có thể chứa tham số theo dõi UTM, chuyển hướng phát hiện thiết bị, chuyển hướng khu vực, v.v. Sử dụng công cụ này có thể: 1) Nhập URL liên kết ngắn (chứa http:// hoặc https://); 2) Nhấp theo dõi xem đường dẫn đầy đủ của mỗi bước nhảy; 3) Xem URL đích cuối cùng, số lần nhảy, loại mã trạng thái; 4) Kiểm tra chuyển hướng trung gian có hạ cấp HTTP hoặc xuyên miền bất thường hay không. Lưu ý: một số liên kết ngắn trả về mục tiêu cuối cùng khác nhau tùy thuộc vào User-Agent hoặc IP khu vực, công cụ này sử dụng IP máy chủ để yêu cầu, có thể hơi khác so với kết quả bạn thấy khi truy cập trực tiếp bằng trình duyệt (đặc biệt là dịch vụ liên kết ngắn nước ngoài). Đối với liên kết ngắn url.cn của WeChat/QQ, có thể cần trong môi trường WeChat mới có thể nhảy đúng đến trang đích.

Chuyển hướng bắt buộc HTTPS dùng 301 hay 302? Cần thêm HSTS không?

Chuyển hướng bắt buộc HTTPS nên sử dụng chuyển hướng vĩnh viễn 301, vì từ HTTP sang HTTPS là thay đổi vĩnh viễn, không phải nhảy tạm thời. Sau khi cấu hình 301 cũng nên triển khai tiêu đề phản hồi HSTS. Kế hoạch bắt buộc HTTPS hoàn chỉnh chia thành ba giai đoạn: 1) Giai đoạn đầu (kỳ kiểm thử): trước tiên cấu hình chuyển hướng 301 HTTP→HTTPS, không bật HSTS, quan sát 1-2 tuần xác nhận tất cả tài nguyên và tên miền con đều hoạt động bình thường; 2) Giai đoạn ổn định: thêm tiêu đề phản hồi Strict-Transport-Security, ban đầu max-age đặt thời gian ngắn hơn (như max-age=300 tức 5 phút), từng bước tăng lên max-age=31536000 (1 năm); 3) Giai đoạn Preload: sau khi xác nhận tất cả tên miền con đều hỗ trợ HTTPS, thêm includeSubDomains và chỉ thị preload, sau đó gửi lên HSTS Preload List (hstspreload.org), làm cho trình duyệt tích hợp sẵn chính sách HSTS tên miền của bạn, loại bỏ cửa sổ HTTP của lần truy cập đầu tiên. Lưu ý rằng một khi HSTS có hiệu lực và được trình duyệt bộ nhớ đệm, trước khi max-age hết hạn không thể thu hồi thông qua phía máy chủ, vì vậy hãy chắc chắn kiểm thử đầy đủ.

Chuyển hướng window.location của JavaScript và chuyển hướng HTTP có gì khác biệt?

Chuyển hướng JS (như window.location.href='https://example.com') và chuyển hướng HTTP 3xx có sự khác biệt về bản chất: 1) Cấp độ thực hiện: chuyển hướng HTTP ở lớp giao thức được máy chủ trả về mã trạng thái, trình duyệt nhảy ngay khi nhận được tiêu đề phản hồi; Chuyển hướng JS cần HTML tải xuống, JS phân tích và thực thi xong mới nhảy, tốc độ chậm hơn; 2) SEO: Trình thu thập dữ liệu công cụ tìm kiếm có thể nhận dạng và theo dõi đúng chuyển hướng HTTP 301/302 để truyền trọng số, nhưng hiệu quả SEO của chuyển hướng JS phụ thuộc vào việc trình thu thập dữ liệu có thực thi JS hay không và thời điểm thực thi, tín hiệu yếu và không ổn định; 3) Liên kết trung gian: Trước khi nhảy JS trang đã bắt đầu tải (có thể xuất hiện màn hình trắng hoặc một phần nội dung nhấp nháy), người dùng chuyển hướng HTTP trực tiếp đến trang đích, trải nghiệm mượt mà hơn; 4) Độ tin cậy: JS có thể bị trình duyệt, tiện ích hoặc Content Security Policy chặn, chuyển hướng HTTP được xử lý cốt lõi của trình duyệt, độ tin cậy cao nhất. Kết luận: Khi cần chuyển hướng URL vĩnh viễn/tạm thời, luôn sử dụng chuyển hướng HTTP phía máy chủ 301/302, chuyển hướng JS chỉ dùng cho điều hướng trang trong logic tương tác (như nhảy sau khi xác minh biểu mẫu, nhấp nút nhảy, v.v.).

Chuỗi chuyển hướng có khiến kết quả kiểm thử A/B không chính xác không?

Có, chuỗi chuyển hướng có nhiều ảnh hưởng đến kiểm thử A/B: 1) Nếu kiểm thử A/B được thực hiện thông qua chuyển hướng (50% người dùng 302 đến phiên bản A, 50% đến phiên bản B), độ trễ chuyển hướng sẽ làm tốc độ tải trang của hai phiên bản khác nhau, bản thân tốc độ có thể ảnh hưởng đến tỷ lệ chuyển đổi (phiên bản nhanh天然 tỷ lệ chuyển đổi cao), dẫn đến sai lệch kiểm thử; 2) Trong quá trình chuyển hướng có thể mất tham số UTM hoặc dấu hiệu nguồn gốc, dẫn đến dữ liệu quy nhân không chính xác; 3) Nếu chuyển hướng 302 kéo dài quá lâu, Google có thể tự ý phán đoán là 301 truyền trọng số, ảnh hưởng đến SEO của trang kiểm thử; 4) Nếu một bước nào đó trong chuỗi chuyển hướng nhiều bước đặt Cookie, có thể ảnh hưởng đến logic phân nhóm người dùng. Khuyến nghị kiểm thử A/B sử dụng phân luồng kết xuất phía máy chủ hoặc phân luồng JS phía client (như Google Optimize、Optimizely), tránh sử dụng phân luồng chuyển hướng. Nếu phải dùng chuyển hướng (như kiểm thử hoàn toàn khác nhau đường dẫn URL), sử dụng 302 (không phải 301) và đảm bảo một bước nhảy đến trực tiếp, sau khi kết thúc kiểm thử hãy kịp thời loại bỏ chuyển hướng.

Làm sao để kiểm tra hàng loạt chuỗi chuyển hướng của toàn bộ trang web?

Kiểm tra hàng loạt chuỗi chuyển hướng trang web cần kết hợp công cụ thu thập dữ liệu: 1) Sử dụng công cụ thu thập dữ liệu như Screaming Frog SEO Spider để thu thập toàn bộ trang web, xem tất cả URL chuyển hướng và độ dài chuỗi trong báo cáo Redirect Chains; 2) Sử dụng chức năng kiểm toán trang web của các công cụ SEO như Ahrefs、Semrush hoặc Sitebulb, chúng sẽ tự động phát hiện chuỗi chuyển hướng và vòng lặp; 3) Đối với danh sách các trang cốt lõi, có thể viết kịch bản gọi API后端 của công cụ này để kiểm tra hàng loạt; 4) Xem gợi ý về「lỗi chuyển hướng」và「chuỗi chuyển hướng quá dài」trong báo cáo「chỉ mục trang」của Google Search Console; 5) Sử dụng kiểm toán Lighthouse của Chrome DevTools, phần Performance sẽ đánh dấu vấn đề chuyển hướng. Khuyến nghị ưu tiên kiểm tra: trang chủ, các trang điều hướng chính, trang đích lưu lượng cao, các trang mới di chuyển/cải tạo, tất cả URL HTTP sau khi chuyển đổi HTTPS, tất cả URL dưới tên miền cũ.

术语表

chuyển hướng (Redirect)
Cơ chế mà máy chủ指示 máy khách tự động truy cập URL khác bằng cách trả về mã trạng thái 3xx và tiêu đề phản hồi Location. Chuyển hướng thường trong suốt đối với người dùng, trình duyệt sẽ tự động theo dõi nhảy.
301 Moved Permanently
Mã trạng thái chuyển hướng vĩnh viễn. Biểu thị tài nguyên đã được di chuyển vĩnh viễn đến vị trí mới, công cụ tìm kiếm sẽ truyền PageRank của URL cũ sang URL mới, trình duyệt sẽ bộ nhớ đệm dài hạn chuyển hướng này. Trong trường hợp yêu cầu GET, khuyến nghị dùng cho di chuyển tên miền, chuyển đổi HTTPS và các thay đổi vĩnh viễn khác.
302 Found
Mã trạng thái chuyển hướng tạm thời (trước đây gọi là Moved Temporarily). Biểu thị tài nguyên tạm thời nằm ở vị trí khác, công cụ tìm kiếm sẽ không chuyển trọng số, trình duyệt không bộ nhớ đệm dài hạn. Lưu ý: yêu cầu POST nhận được 302 sau đó đa số trình duyệt sẽ chuyển thành yêu cầu GET để chuyển hướng, có thể làm mất nội dung yêu cầu.
303 See Other
Mã trạng thái xem vị trí khác. Thường dùng cho nhảy trang kết quả sau khi gửi biểu mẫu POST, rõ ràng yêu cầu máy khách yêu cầu URL mới bằng phương thức GET, ngăn chặn việc gửi lại biểu mẫu. Phản hồi 303 không nên được bộ nhớ đệm.
307 Temporary Redirect
Mã trạng thái chuyển hướng tạm thời (được giới thiệu trong HTTP/1.1). Ngữ nghĩa giống 302, nhưng yêu cầu nghiêm ngặt giữ lại phương thức yêu cầu và nội dung yêu cầu — yêu cầu POST nhận được 307 sau đó phải vẫn yêu cầu URL mới bằng cách POST, sẽ không làm mất dữ liệu biểu mẫu. Phù hợp cho nhảy tạm thời của API và biểu mẫu.
308 Permanent Redirect
Mã trạng thái chuyển hướng vĩnh viễn (được định nghĩa trong RFC 7538). Ngữ nghĩa giống 301, nhưng yêu cầu nghiêm ngặt giữ lại phương thức yêu cầu và nội dung yêu cầu — yêu cầu POST nhận được 308 sau đó vẫn chuyển hướng bằng cách POST. Là phiên bản "an toàn phương thức" của 301, trình duyệt hiện đại đã hỗ trợ hoàn toàn.
Tiêu đề Location
Trường tiêu đề phản hồi HTTP, dùng để chỉ định URL đích trong phản hồi chuyển hướng 3xx. Có thể là URL tuyệt đối (khuyến nghị) hoặc URL tương đối, máy khách nhận được sau đó tự động发起 yêu cầu mới đến URL đó. Ký tự không phải ASCII trong tiêu đề Location phải được mã hóa URL.
Chuỗi chuyển hướng (Redirect Chain)
Một loạt các chuyển hướng liên tiếp giữa URL ban đầu và URL đích cuối cùng. Ví dụ A→B→C→D tạo thành một chuỗi chuyển hướng 3 bước. Chuỗi chuyển hướng quá dài sẽ làm chậm tốc độ tải, làm hao tổn trọng số SEO, khuyến nghị kiểm soát ở một bước, tối đa không quá 3 bước.
Vòng lặp chuyển hướng (Redirect Loop)
Một URL lặp lại xuất hiện trong chuỗi chuyển hướng, tạo thành vòng lặp nhảy vô hạn (như A→B→A). Trình duyệt sẽ hiển thị lỗi ERR_TOO_MANY_REDIRECTS sau khi đạt số lần nhảy tối đa (thường 20 lần). Nguyên nhân phổ biến bao gồm HTTP↔HTTPS nhảy qua lại, www↔không phải www nhảy qua lại và mất giao thức proxy ngược.
Di chuyển tên miền (Domain Migration)
Quá trình trang web chuyển vĩnh viễn từ một tên miền sang tên miền khác, như thương hiệu thay đổi tên miền, công ty mua bán sáp nhập. Khi di chuyển cần chuyển hướng vĩnh viễn 301 tất cả URL của tên miền cũ đến trang tương ứng của tên miền mới, và gửi thông báo thay đổi tên miền trong Google Search Console.
Chuẩn hóa URL (URL Canonicalization)
Quá trình thống nhất nhiều biến thể URL của cùng một nội dung (www/không phải www, có/không dấu gạch chéo cuối, HTTP/HTTPS, khác biệt chữ hoa chữ thường) thành URL chuẩn duy nhất, thường được thực hiện thông qua chuyển hướng 301. Chuẩn hóa tránh vấn đề nội dung lặp lại, tập trung trọng số SEO.
Chuyển hướng bắt buộc HTTPS
Cấu hình chuyển hướng tất cả các yêu cầu HTTP (cổng 80) đến HTTPS (cổng 443) thông qua 301, là bước cần thiết sau khi triển khai chứng chỉ SSL/TLS. Thường kết hợp với tiêu đề phản hồi HSTS, loại bỏ cửa sổ văn bản HTTP của lần truy cập đầu tiên.
HSTS
HTTP Strict Transport Security (an ninh truyền nghiêm ngặt), thông qua tiêu đề phản hồi Strict-Transport-Security nói với trình duyệt trong thời gian chỉ định chỉ có thể truy cập tên miền này thông qua HTTPS, trình duyệt bên trong tự động nâng HTTP lên HTTPS, không cần máy chủ chuyển hướng. Phòng ngừa hiệu quả tấn công tước đoạt SSL.
Liên kết ngắn (Short URL)
Dịch vụ chuyển đổi URL dài thành URL ngắn (như bit.ly、t.cn), khi truy cập thông qua chuyển hướng 301/302 để nhảy URL ngắn đến URL dài gốc. Phía sau liên kết ngắn thường ẩn chứa chuỗi nhảy nhiều bước, có thể chứa tham số theo dõi hoặc nhảy đến mục tiêu khác nhau trong điều kiện cụ thể.
PageRank
Thuật toán xếp hạng trang web do người sáng lập Google Larry Page và Sergey Brin phát minh, đánh giá tính uy quyền của trang thông qua quan hệ liên kết. Chuyển hướng vĩnh viễn 301 sẽ truyền PageRank của URL cũ sang URL mới, trong khi chuyển hướng tạm thời 302 thường không truyền hoặc truyền rất ít.
Core Web Vitals
Chỉ số trải nghiệm trang web cốt lõi do Google định nghĩa, bao gồm LCP (bản vẽ nội dung lớn nhất, đo lường hiệu năng tải, tiêu chuẩn tốt ≤2,5s), FID/INP (độ phản hồi tương tác, tiêu chuẩn tốt ≤100ms/200ms) và CLS (độ ổn định thị giác, tiêu chuẩn tốt ≤0,1). Chuỗi chuyển hướng sẽ trì hoãn tải HTML, trực tiếp làm xấu đi chỉ số LCP.
Chuyển hướng xuyên miền (Cross-origin Redirect)
URL đích chuyển hướng khác với tên miền của URL gốc (bao gồm tên miền hoàn toàn khác hoặc tên miền con khác). Chuyển hướng xuyên miền bị hạn chế bởi chính sách cùng nguồn gốc, có thể dẫn đến Cookie không gửi, Cookie bên thứ ba bị chặn, kiểm tra trước CORS thất bại và các vấn đề khác.
Cắt chuỗi (Chain Truncation)
Khi số bước nhảy của chuỗi chuyển hướng vượt quá giới hạn độ sâu tối đa được đặt bởi công cụ hoặc trình duyệt (công cụ này là 20 bước, Chrome là 20 bước), trình theo dõi ngừng theo dõi các chuyển hướng tiếp theo và đánh dấu chuỗi bị cắt. Cắt chuỗi thường ngụ ý tồn tại vòng lặp vô hạn hoặc cấu hình chuyển hướng bất thường phức tạp.

Bảng đối chiếu đầy đủ mã trạng thái chuyển hướng HTTP

301Moved PermanentlyCó (vĩnh viễn)Có thể thay đổi (POST→GET)Di chuyển tên miền, chuyển đổi HTTPS, chuẩn hóa www/không phải www, thay đổi vĩnh viễn URL
302FoundKhông (tạm thời)Có thể thay đổi (POST→GET)Trang bảo trì tạm thời, nhảy đăng nhập, kiểm thử A/B, trang hoạt động ngắn hạn
303See OtherKhông (tạm thời)Có (bắt buộc GET)Sau khi gửi biểu mẫu POST nhảy đến trang kết quả, ngăn chặn gửi lại
307Temporary RedirectKhông (tạm thời)Không (giữ nguyên nghiêm ngặt phương thức gốc)Chuyển hướng tạm thời API, nhảy tạm thời cần giữ lại dữ liệu POST
308Permanent RedirectCó (vĩnh viễn)Không (giữ nguyên nghiêm ngặt phương thức gốc)Di chuyển vĩnh viễn API RESTful, chuyển hướng vĩnh viễn cần giữ lại phương thức PUT/DELETE

Bảng đối chiếu ảnh hưởng chuỗi chuyển hướng đối với SEO

0 bước (đến trực tiếp)Không ảnh hưởng, trạng thái tốt nhấtKhông có độ trễ bổ sungGiữ nguyên hiện trạng, liên kết nội bộ trực tiếp trỏ đến URL cuối cùng
1 bướcPageRank truyền bình thường, ảnh hưởng SEO có thể bỏ quaTăng khoảng 100-300ms độ trễ (một vòng đi lại)Có thể chấp nhận, số bước nhảy phổ biến của HTTP→HTTPS và chuẩn hóa tên miền
2 bướcTruyền trọng số có thể suy giảm nhẹ, trình thu thập dữ liệu có thể theo dõi bình thườngTăng khoảng 200-600ms độ trễKhuyến nghị tối ưu thành một bước, kiểm tra liên kết nội bộ có trỏ đến URL chuyển hướng trung gian hay không
3 bướcHiệu quả truyền trọng số giảm, một số trình thu thập dữ liệu có thể từ bỏ theo dõiTăng khoảng 300-900ms độ trễ, LCP có thể bị ảnh hưởngCần phải tối ưu, hợp nhất quy tắc chuyển hướng trực tiếp đến URL cuối cùng
4-5 bướcPageRank suy giảm rõ rệt, việc thu thập có thể bị ảnh hưởng, lãng phí ngân sách thu thậpTăng 500ms-1,5s độ trễ, LCP rất có thể vượt tiêu chuẩnSửa chữa khẩn cấp, kiểm tra chồng chất chuyển hướng đa lớp CDN/nguồn站/ứng dụng
6 bước以上Rủi ro nghiêm trọng, công cụ tìm kiếm có thể ngừng theo dõi dẫn đến trang bị loại khỏi chỉ mụcĐộ trễ vượt quá 1 giây trở lên, trải nghiệm người dùng cực kỳ kémNgay lập tức kiểm tra vòng lặp hoặc lỗi cấu hình, tái cấu trúc quy tắc chuyển hướng
Vòng lặp (ERR_TOO_MANY_REDIRECTS)Trang hoàn toàn không thể truy cập, công cụ tìm kiếm sẽ loại bỏ nó khỏi chỉ mụcTrang không thể tải, trình duyệt hiển thị lỗiSửa chữa ưu tiên cao nhất, sử dụng công cụ này định vị nút vòng lặp

Các lỗi cấu hình chuyển hướng phổ biến và giải pháp sửa chữa

Lỗi vòng lặp ERR_TOO_MANY_REDIRECTS, HTTP↔HTTPS nhảy qua lại liên tụcCDN/cân bằng tải quay nguồn bằng HTTP, nguồn站 không xử lý đúng tiêu đề X-Forwarded-Proto, luôn chuyển hướng đến HTTPSTrong cấu hình Nginx thêm: set $forwarded_scheme $http_x_forwarded_proto; if ($forwarded_scheme != "https") { return 301 https://$host$request_uri; } hoặc sử dụng biến $scheme kết hợp với cấu hình proxy_set_header X-Forwarded-Proto
www và không phải www nhảy qua lại tạo thành vòng lặpLớp CDN cấu hình chuyển hướng www→không phải www, Nginx nguồn站 lại cấu hình chuyển hướng không phải www→www, quy tắc xung độtChọn một phiên bản chuẩn hóa (khuyến nghị không phải www hoặc www, giữ nhất quán), chỉ cấu hình chuyển hướng ở một lớp (CDN hoặc nguồn站), xóa quy tắc tương ứng của các lớp khác
Chuỗi chuyển hướng经过 4-5 bước mới đến trang cuối cùngBước nhảy HTTP→HTTPS→bước nhảy không phải www→www→bước nhảy thêm dấu gạch chéo cuối→bước nhảy đường dẫn cũ sang đường dẫn mới, chồng chất quy tắc đa lớpHợp nhất quy tắc chuyển hướng, trực tiếp từ URL ban đầu một bước nhảy đến URL cuối cùng. Trong Nginx sử dụng chỉ thị return để một lần nhảy đến địa chỉ cuối cùng hoàn chỉnh
Trong chuỗi chuyển hướng trang web HTTPS xuất hiện nút HTTP (hạ cấp)Trong cấu hình máy chủ đã mã hóa cứng mục tiêu chuyển hướng tiền tố http://, hoặc ứng dụng tạo URL chuyển hướng không nhận diện hiện tại là HTTPSCấu hình ứng dụng tin tưởng proxy ngược, đọc đúng X-Forwarded-Proto; trong Nginx sử dụng URL tuyệt đối https:// hoặc biến $scheme (điều kiện là proxy đã đặt đúng scheme); triển khai HSTS
Sau khi sửa đổi chuyển hướng 301 trình duyệt vẫn nhảy đến địa chỉ cũTrình duyệt bộ nhớ đệm dài hạn quy tắc chuyển hướng vĩnh viễn 301, làm mới F5 không hiệu quảGiai đoạn kiểm thử sử dụng chuyển hướng tạm thời 302 sau khi xác nhận không lỗi mới đổi thành 301; xóa bộ nhớ đệm trình duyệt (Chrome: cài đặt→quyền riêng tư→xóa dữ liệu duyệt web→ảnh và tệp được lưu trong bộ nhớ đệm); sử dụng tùy chọn Disable cache của DevTools
Dữ liệu biểu mẫu bị mất sau khi chuyển hướng yêu cầu POSTĐã sử dụng chuyển hướng 301 hoặc 302, trình duyệt tự động chuyển POST thành yêu cầu GET, nội dung yêu cầu bị loại bỏĐối với các yêu cầu không phải GET như POST/PUT/DELETE,改用 chuyển hướng 307 (tạm thời) hoặc 308 (vĩnh viễn), giữ nghiêm ngặt phương thức yêu cầu và nội dung yêu cầu
Sau chuyển hướng URL xuất hiện các ký tự mã hóa kép như %2520Tham số URL đã được mã hóa URL một lần, máy chủ lại mã hóa lần thứ hai khi chuyển hướngKiểm tra logic chuyển hướng, đảm bảo URL chỉ được mã hóa một lần; trong Nginx sử dụng $request_uri (URI gốc, chưa được giải mã) thay vì $uri (đã được giải mã)
Sau khi chuyển hướng xuyên miền yêu cầu AJAX/fetch báo lỗi CORSMáy chủ đích của chuyển hướng xuyên miền không cấu hình tiêu đề phản hồi CORS (Access-Control-Allow-Origin, v.v.)Đảm bảo mỗi bước nhảy trong chuỗi chuyển hướng đều cấu hình đúng tiêu đề CORS; hoặc tránh sử dụng chuyển hướng xuyên miền trong yêu cầu AJAX,改成 phía frontend lấy URL đích sau đó yêu cầu trực tiếp

Troubleshooting