逐跳檢查 301/302/307/308，識別循環、跨域重新導向與 HTTPS 降級問題。
當你在瀏覽器中輸入一個網址時，幕後可能發生了一連串你看不見的跳轉：HTTP→HTTPS、非www→www、舊網域→新網域、短連結→長連結……每一跳重新導向都在消耗時間、影響SEO排名、甚至可能悄悄將HTTPS降級為HTTP。重新導向鏈檢查器以伺服器視角逐跳追蹤URL的完整跳轉路徑，展示每一跳的狀態碼（301/302/303/307/308）、Location標頭和目標位址，自動偵測循環跳轉、跨域跳轉、HTTPS降級和鏈路截斷等問題，幫助你在網域名稱搬移、HTTPS部署和SEO最佳化中發現隱藏的重新導向隱患。
Google官方建議重新導向鏈控制在單跳，最多不超過3跳。根據Google Search Central文件，Googlebot通常遵循最多5個重新導向跳數後停止追蹤，但這並不意味著5跳是安全的。每跳重新導向都會增加頁面載入延遲（100-300ms/跳）、浪費爬取預算、並可能導致PageRank傳遞衰減。1跳幾乎無SEO影響；2跳可接受但建議最佳化；3跳以上開始影響LCP和爬取效率；5跳以上存在頁面不被收錄的風險。使用本工具偵測你的核心頁面跳轉鏈，確保關鍵URL（首頁、核心產品頁、高流量內頁）都是單跳直達。
正確使用的301永久重新導向不會傷害SEO。Google的Gary Illyes和John Mueller多次確認，301重新導向從HTTP網域搬移到HTTPS網域，以及在同一網域內的頁面永久搬移，PageRank傳遞是100%的，沒有損失。但需要注意：1) 302暫時重新導向不傳遞PageRank（或傳遞效率極低）；2) 重新導向鏈中如果出現noindex、robots.txt屏蔽、4xx/5xx錯誤，權重傳遞會中斷；3) 跨域301搬移後，需要在Google Search Console提交網域變更通知加速索引搬移；4) 301會被瀏覽器長期快取，測試階段建議先用302驗證再改為301。
HTTPS→HTTP降級跳轉通常由以下原因導致：1) 反向代理/CDN以HTTP回源，來源端Nginx/Apache使用$scheme變數取得協定時得到的是http而非https；2) 應用層程式碼中硬編碼了http://前綴的URL；3) WordPress等CMS的Home URL或Site URL設定為http；4) .htaccess中存在舊的HTTP規則殘留；5) 第三方服務（CDN/WAF）的SSL/TLS設定為「彈性」模式而非「嚴格」模式。修復步驟：首先用本工具確定降級發生在哪一跳；CDN設定SSL為「Full (strict)」模式；Nginx中正確處理X-Forwarded-Proto標頭；WordPress在wp-config.php中新增$_SERVER['HTTPS']='on'; 部署HSTS回應標頭防止瀏覽器層面降級；檢查所有重新導向規則確保目標為https://。
Nginx重新導向循環90%以上是反向代理/CDN場景下X-Forwarded-Proto標頭未正確處理導致的。修復方法：1) 確保CDN/負載平衡向後端發送X-Forwarded-Proto標頭：proxy_set_header X-Forwarded-Proto $scheme; 2) Nginx判斷時使用X-Forwarded-Proto而非$scheme來決定是否跳轉HTTPS。推薦使用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) 避免在server塊中寫rewrite規則無限匹配自身；4) www和非www重新導向只在一個server塊中設定單向跳轉，不要雙向設定。
Apache .htaccess循環通常由RewriteRule規則衝突導致。修復步驟：1) 確保RewriteEngine On只出現一次；2) HTTP→HTTPS跳轉規則放在所有規則最前面，使用：RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]；3) www/非www規則放在HTTPS跳轉之後，且只做單向跳轉（非www→www或反之）；4) 注意[L]標誌的含義是「last」但如果規則修改了URL會重新從第一條開始匹配，可能導致循環，複雜規則考慮使用[END]標誌（Apache 2.3.9+）；5) 檢查是否有多個.htaccess檔案（子目錄中的.htaccess也會生效）；6) 臨時將R=301改為R=302測試，避免瀏覽器快取干擾。
Cloudflare循環最常見的原因是SSL/TLS加密模式設定錯誤或頁面規則衝突：1) 將Cloudflare SSL/TLS模式從「Flexible」改為「Full」或「Full (strict)」——Flexible模式下Cloudflare到來源端用HTTP，來源端如果設定了HTTPS強制跳轉就會循環；2) 檢查Cloudflare的「Edge Certificates」中的「Always Use HTTPS」是否開啟，不要同時在來源端和Cloudflare重複設定HTTPS跳轉；3) 檢查Page Rules中是否有互相衝突的轉發規則；4) 如果使用了Cloudflare WordPress外掛，不要同時在外掛和Cloudflare中設定HTTPS重新導向；5) 檢查Forwarding URL規則是否指向了又被Cloudflare重新導向的位址。
核心區別在「是否永久」和「是否保留請求方法」兩個維度。快速選擇指南：對於普通網頁GET請求（使用者存取頁面）——永久搬移用301（網域名稱搬移、HTTPS切換、URL永久變更），臨時跳轉用302（A/B測試、臨時維護、登入跳轉）；對於POST/PUT/DELETE請求（API呼叫、表單提交）——永久搬移用308，臨時跳轉用307，確保請求方法和請求本體不遺失；303專門用於POST表單提交後跳轉到結果頁（強制GET，防止重複提交）。簡單記憶：301=永久GET安全，302=臨時GET安全，307=臨時全方法，308=永久全方法，303=POST後跳結果頁。
301永久重新導向預設會被瀏覽器快取，但快取時間取決於回應標頭中的Cache-Control和Expires設定。如果沒有顯式指定快取標頭，不同瀏覽器的預設快取行為不同：Chrome通常快取301重新導向數周到數月（甚至直到瀏覽器重啟後仍可能快取）；Firefox預設快取301但在瀏覽器重啟後可能重新驗證；Safari的快取策略相對保守。清除301快取的方法：1) Chrome：設定→隱私和安全→清除瀏覽資料→時間範圍選「所有時間」→勾選「快取的圖片和檔案」→清除資料；2) 開發者工具（F12）打開時勾選Network面板的「Disable cache」；3) 在URL後新增無意義查詢參數（?nocache=1）繞過快取；4) Chrome開發者可以在chrome://net-internals/#sockets中Flush sockets，或在chrome://net-internals/#dns中Clear host cache；5) 測試階段使用302暫時重新導向代替301，確認無誤後再改為301。
Meta Refresh是HTML文件中的<meta>標籤實現的重新導向（如<meta http-equiv="refresh" content="0;url=https://example.com/new">），在瀏覽器端解析HTML後執行跳轉，而HTTP重新導向透過3xx狀態碼在HTTP協定層面由伺服器直接指示跳轉。區別對比：1) 速度：HTTP重新導向在收到回應標頭時就開始跳轉，Meta Refresh需要等待HTML下載並解析後才跳轉，速度更慢；2) SEO：Google通常能識別Meta Refresh並傳遞權重（如果delay=0），但官方推薦使用HTTP 301/302重新導向，因為Meta Refresh是用戶端跳轉，訊號不如服務端重新導向明確；3) 延遲：Meta Refresh可以設定延遲時間（如content="5;url=..."表示5秒後跳轉），但HTTP重新導向沒有這個功能；4) 可存取性：W3C不推薦使用Meta Refresh，因為螢幕閱讀器等輔助技術處理不佳，也可能使用者困惑；5) 後退按鈕：Meta Refresh在某些瀏覽器中可能破壞後退按鈕行為。結論：始終優先使用HTTP 301/302/307/308重新導向，避免使用Meta Refresh，除非你無法控制伺服器設定（如託管在靜態頁面平台無法設定服務端規則）。
會，且影響非常大。重新導向發生在瀏覽器取得HTML文件之前，這意味著每跳重新導向都會延遲HTML文件的開始下載時間。LCP（Largest Contentful Paint，最大內容繪製）的計算起點是導航開始時間，而瀏覽器必須在獲得最終HTML後才能開始解析DOM、載入CSS和轉譯LCP元素。假設每跳重新導向增加150ms網路延遲（DNS+TCP+TLS+請求回應），3跳重新導向就會讓LCP至少增加450ms，這足以將LCP從「良好」（≤2.5s）推到「需要改進」（2.5-4s）區間。Google的Core Web Vitals文件明確將「避免多次重新導向」作為最佳化LCP的關鍵建議之一。最佳實務：確保核心頁面零重新導向（直接連結最終URL），HTTP→HTTPS和www正規化這類必要重新導向控制在單跳。
短連結（t.cn、bit.ly、dwz.cn、url.cn等）通常透過1-3跳重新導向到達最終URL，中間可能包含UTM追蹤參數、裝置偵測跳轉、地域跳轉等。使用本工具可以：1) 輸入短連結URL（包含http://或https://）；2) 點擊追蹤查看每一跳的完整路徑；3) 查看最終落地URL、跳轉次數、狀態碼類型；4) 檢查中間跳轉是否有HTTP降級或異常跨域。注意：部分短連結根據User-Agent或IP地域返回不同的最終目標，本工具使用伺服器IP請求，可能與你瀏覽器直接存取看到的結果略有差異（尤其是海外短連結服務）。對於微信/QQ的url.cn短連結，可能需要在微信環境內才能正確跳轉到目標頁。
HTTPS強制跳轉應該使用301永久重新導向，因為從HTTP到HTTPS是永久性的變更，不是臨時跳轉。設定301後還應該部署HSTS回應標頭。完整的HTTPS強制方案分三個階段：1) 第一階段（測試期）：先設定HTTP→HTTPS 301重新導向，不啟用HSTS，觀察1-2週確認所有資源和子網域都正常工作；2) 第二階段（穩定期）：新增Strict-Transport-Security回應標頭，初始max-age設為較短時間（如max-age=300即5分鐘），逐步增加到max-age=31536000（1年）；3) 第三階段（Preload）：確認所有子網域都支援HTTPS後，新增includeSubDomains和preload指令，然後提交到HSTS Preload List（hstspreload.org），使瀏覽器內建你的網域HSTS策略，消除首次存取的HTTP視窗。注意HSTS一旦在瀏覽器中快取，在max-age到期前無法透過伺服器端撤銷，所以務必充分測試。
JavaScript跳轉（如window.location.href='https://example.com'）與HTTP 3xx重新導向有本質區別：1) 執行層級：HTTP重新導向在協定層由伺服器返回狀態碼，瀏覽器在收到回應標頭時立即跳轉；JS跳轉需要HTML下載、JS解析執行後才跳轉，速度更慢；2) SEO：搜尋引擎爬蟲能正確識別並跟蹤HTTP 301/302重新導向傳遞權重，但JS跳轉的SEO效果取決於爬蟲是否執行JS以及執行時機，訊號弱且不穩定；3) 中間環節：JS跳轉前頁面已經開始載入（可能出現白屏或部分內容閃爍），HTTP重新導向使用者直接到達目標頁，體驗更流暢；4) 可靠性：JS可能被瀏覽器、外掛或Content Security Policy阻止，HTTP重新導向由瀏覽器核心處理，可靠性最高。結論：需要永久/臨時跳轉URL時，始終使用服務端HTTP 301/302重新導向，JS跳轉僅用於互動邏輯中的頁面導航（如表單驗證後跳轉、按鈕點擊跳轉等）。
會的，重新導向鏈對A/B測試有多方面影響：1) 如果A/B測試透過重新導向實現（50%使用者302到版本A，50%到版本B），重新導向延遲會讓兩個版本的頁面載入速度不同，速度本身可能影響轉化率（速度快的版本天然轉化率高），導致測試偏差；2) 重新導向過程中可能遺失UTM參數或來源標記，導致歸因資料不準確；3) 302重新導向如果持續時間過長，Google可能自行判斷為301傳遞權重，影響測試頁面的SEO；4) 多跳重新導向中如果某跳設定了Cookie，可能影響使用者分組邏輯。建議A/B測試使用服務端轉譯分流或用戶端JS分流（如Google Optimize、Optimizely），避免使用重新導向分流。如果必須用重新導向（如測試完全不同的URL路徑），使用302（非301）並確保單跳直達，測試結束後及時移除重新導向。
批次檢查網站重新導向鏈需要結合爬蟲工具：1) 使用Screaming Frog SEO Spider等爬蟲工具爬取整個網站，在Redirect Chains報告中查看所有重新導向URL和鏈長度；2) 使用Ahrefs、Semrush或Sitebulb等SEO工具的站點審計功能，它們會自動偵測重新導向鏈和循環；3) 對於核心頁面列表，可以編寫指令稿呼叫本工具的後端API批次偵測；4) 在Google Search Console的「頁面索引」報告中查看「重新導向錯誤」和「重新導向鏈過長」的提示；5) 使用Chrome DevTools的Lighthouse審計，Performance部分會標記重新導向問題。建議優先檢查：首頁、主要導航頁、高流量著陸頁、最近搬移/改版的頁面、HTTPS切換後所有HTTP URL、舊網域下的所有URL。
301 | Moved Permanently | 是（永久） | 可能改變（POST→GET） | 網域名稱搬移、HTTPS切換、www/非www正規化、URL永久變更 |
302 | Found | 否（暫時） | 可能改變（POST→GET） | 暫時維護頁、登入跳轉、A/B測試、短期活動頁 |
303 | See Other | 否（暫時） | 是（強制GET） | POST表單提交後跳轉到結果頁，防止重複提交 |
307 | Temporary Redirect | 否（暫時） | 否（嚴格保留原方法） | API暫時重新導向、需要保留POST資料的臨時跳轉 |
308 | Permanent Redirect | 是（永久） | 否（嚴格保留原方法） | RESTful API永久搬移、需要保留PUT/DELETE方法的永久重新導向 |
| 0跳（直接到達） | 無影響，最佳狀態 | 無額外延遲 | 保持現狀，內部連結直接指向最終URL |
| 1跳 | PageRank正常傳遞，SEO影響可忽略 | 增加約100-300ms延遲（一次往返） | 可接受，HTTP→HTTPS和網域正規化的常見跳數 |
| 2跳 | 權重傳遞可能有輕微衰減，爬蟲可正常跟蹤 | 增加約200-600ms延遲 | 建議最佳化為單跳，檢查內部連結是否指向了中間跳轉URL |
| 3跳 | 權重傳遞效率下降，部分爬蟲可能放棄追蹤 | 增加約300-900ms延遲，LCP可能受影響 | 必須最佳化，合併重新導向規則直接到最終URL |
| 4-5跳 | PageRank明顯衰減，收錄可能受影響，爬取預算浪費 | 增加500ms-1.5s延遲，LCP大概率超標 | 緊急修復，檢查CDN/來源端/應用多層重新導向疊加 |
| 6跳以上 | 嚴重風險，搜尋引擎可能停止追蹤導致頁面脫收錄 | 延遲超過1秒以上，使用者體驗極差 | 立即排查循環或設定錯誤，重構重新導向規則 |
| 循環（ERR_TOO_MANY_REDIRECTS） | 頁面完全無法存取，搜尋引擎將其從索引中移除 | 頁面無法載入，瀏覽器顯示錯誤 | 最高優先級修復，使用本工具定位循環節點 |
| ERR_TOO_MANY_REDIRECTS循環錯誤，HTTP↔HTTPS反覆跳轉 | CDN/負載平衡以HTTP回源，來源端正確處理X-Forwarded-Proto標頭，始終重新導向到HTTPS | Nginx設定中新增：set $forwarded_scheme $http_x_forwarded_proto; if ($forwarded_scheme != "https") { return 301 https://$host$request_uri; } 或使用$scheme變數配合proxy_set_header X-Forwarded-Proto設定 |
| www和非www互相跳轉形成循環 | CDN層設定www→非www跳轉，來源端Nginx又設定非www→www跳轉，規則衝突 | 選擇一個正規化版本（推薦非www或www，保持一致），只在一層（CDN或來源端）設定重新導向，刪除其他層的對應規則 |
| 重新導向鏈經過4-5跳才到達最終頁面 | HTTP→HTTPS跳→非www→www跳→加尾斜線跳→舊路徑跳新路徑，多層規則疊加 | 合併重新導向規則，直接從初始URL一步跳到最終URL。Nginx中使用return指令一次性跳轉到完整最終位址 |
| HTTPS站點重新導向鏈中出現HTTP節點（降級） | 伺服器設定中硬編碼了http://前綴的重新導向目標，或應用生成重新導向URL時未識別目前為HTTPS | 設定應用信任反向代理，正確讀取X-Forwarded-Proto；Nginx中使用https://絕對URL或$scheme變數（前提是proxy正確設定了scheme）；部署HSTS |
| 301重新導向修改後瀏覽器仍然跳到舊位址 | 瀏覽器長期快取301永久重新導向規則，F5重新整理無效 | 測試階段使用302暫時重新導向確認無誤後再改為301；清除瀏覽器快取（Chrome：設定→隱私→清除瀏覽資料→快取的圖片和檔案）；使用DevTools的Disable cache選項 |
| POST請求重新導向後表單資料遺失 | 使用了301或302重新導向，瀏覽器自動將POST轉為GET請求，請求本體被丟棄 | 對於POST/PUT/DELETE等非GET請求，改用307（臨時）或308（永久）重新導向，嚴格保留請求方法和請求本體 |
| 重新導向後URL出現%2520等雙重編碼字元 | URL參數已經過一次URL編碼，伺服器重新導向時又對其進行了第二次編碼 | 檢查重新導向邏輯，確保URL只編碼一次；Nginx中使用$request_uri（原始URI，未解碼）而非$uri（已解碼） |
| AJAX/fetch請求跨域重新導向後報CORS錯誤 | 跨域重新導向的目標伺服器未設定CORS回應標頭（Access-Control-Allow-Origin等） | 確保重新導向鏈中每一跳的伺服器都正確設定CORS標頭；或避免在AJAX請求中使用跨域重新導向，改為前端取得目標URL後直接請求 |
