點下去的連結，往往不是最後打開的那個頁面。中間可能經過 HTTPS 升級、主機變更、追蹤服務、短網址服務，以及一條替網址加上結尾斜線的 CMS 規則；每一步都是瀏覽器另外發出的一次要求，而且不會通知您。

本指南說明如何用 TrueURL、curl 和瀏覽器的 DevTools 看見這些步驟、重新導向鏈中每個部分代表的意義，以及如何修正最常見的問題。

什麼是重新導向鏈

當伺服器以 3xx 狀態碼回應，並在 Location 標頭中指定另一個 URL 時，就發生了重新導向。用戶端（瀏覽器或爬蟲）接著會要求該 URL，並重複這個過程，直到收到不是重新導向的回應為止。

每一組要求與回應構成一個躍點（hop）。從第一個網址到最終回應的整個過程，就是重新導向鏈：

#  URL                              Status  Location
1  http://example.com/Shoes         301     https://example.com/Shoes
2  https://example.com/Shoes        301     https://www.example.com/Shoes
3  https://www.example.com/Shoes    302     /shoes/
4  https://www.example.com/shoes/   200

為了抵達一個頁面，總共經過 3 次重新導向、發出 4 次要求。第 3 個躍點的 Location 是相對路徑：依照 RFC 9110 的規定，用戶端會以剛剛要求的 URL 為基準來解析它，因此它代表 https://www.example.com/shoes/。理想情況下，這些位址都應該只經過一個躍點就抵達最終網址。

頁面也可能在回應 200 OK 之後，再透過 <meta http-equiv="refresh"> 標記或 JavaScript 進行重新導向。這類用戶端重新導向同樣屬於重新導向鏈的一部分，但 curl 這類只讀取 HTTP 標頭的工具，會停在該頁面。

為什麼要檢查重新導向

SEO：標準網址訊號與檢索預算

搜尋引擎會把重新導向視為一種聲明，表示應該將哪個網址編入索引。Google 將永久重新導向（301 和 308）視為強烈訊號，表示目標網址應該成為標準網址；暫時重新導向（302、303 和 307）則只是微弱的訊號。因此，已經永久搬移、卻使用 302 重新導向的頁面，在搜尋結果中可能仍會顯示舊網址。

長度也很重要。Google 檢索器（Googlebot）最多會追蹤 10 個重新導向躍點；如果到那時仍未取得內容，Search Console 就會回報重新導向錯誤。Google 的檢索預算（crawl budget）指南也建議避免過長的重新導向鏈，並指出這類重新導向鏈會對檢索造成負面影響。

網頁速度

在最後一次重新導向得到回應之前，最終頁面都無法開始載入。每個躍點都要花上一次網路往返；如果躍點連往新的主機，還需要 DNS 查詢、建立新連線，若是 HTTPS 還得進行 TLS 交握。在行動網路上，三、四次重新導向就可能讓真正頁面的第一個位元組晚上數百毫秒才送達。重新導向延遲檢查工具會顯示每個躍點耗費的時間。

短網址與來路不明連結的安全性

短連結和電子郵件中的許多追蹤連結，都會隱藏真正的目的地。網路釣魚活動也會濫用知名網域上的開放式重新導向（open redirect），所以一個從可信網站開始的連結，最後可能會連到完全不同的地方。短網址還原工具能在點擊之前，列出沿途經過的每個網域，並指出是否有任何躍點從 HTTPS 降級為一般 HTTP。

聯盟行銷與追蹤連結

行銷連結在抵達到達網頁之前，常會經過好幾個服務，而每個服務都必須轉送查詢字串，否則 UTM 參數、點擊 ID 和聯盟行銷標記就會在不知不覺中遺失。從最終網址就能看出這些參數是否保留了下來，以及連結是否仍然連到預期的頁面。

網站搬遷、HTTPS 與標準主機

在網站改版、更換網域或改用 HTTPS 之後，每個舊網址都應該透過一次永久重新導向，抵達對應的新網址。網站的四種基本變體（http:// 和 https://，各自含與不含 www）都應該抵達同一個標準位址。這些規則很容易在無聲無息中失效：一條新的 CDN 規則、一次外掛程式更新或一次伺服器搬遷，都可能在沒有人察覺的情況下多出一個躍點或形成迴圈。

如何用 TrueURL 檢查重新導向

TrueURL 的每次檢查都在 Cloudflare 邊緣網路上執行，因此不必在瀏覽器中開啟，就能檢查不信任的連結。首頁的網址重新導向檢查工具一次處理一個網址；重新導向鏈檢查和其他專用工具也使用相同的檢查引擎。

步驟 1：輸入網址

貼上網址並開始檢查。如果沒有輸入通訊協定（scheme），系統會預設為 https://；若要測試一般 HTTP，請輸入 http://。

步驟 2：視需要調整進階設定

檢查工具預設會以較新版本的電腦版 Chrome User-Agent（使用者代理程式）送出 GET 要求，不帶任何 Cookie，最多追蹤 20 次重新導向。進階設定可以變更這些行為：

  • HTTP 方法：GET、HEAD 或 POST。HEAD 比較輕量，但有些伺服器對它的回應不同，而且少了回應主體，就無法偵測用戶端重新導向。POST 會送出您輸入的要求主體，適用於表單處理程式和 API。後續躍點會遵循瀏覽器的規則：在 POST 之後，301 或 302 會改以 GET 繼續，303 則一律改用 GET，307 和 308 會保留原本的方法與主體。
  • 最大躍點數：要追蹤的重新導向次數，範圍是 1 到 50。預設值 20 與 Fetch Standard 以及 Chrome 和 Firefox 的上限相同。設為 10，即可確認重新導向鏈是否在 Googlebot 的上限之內。
  • 自訂 User-Agent：留空即使用電腦版 Chrome。內建選項包括 iPhone 上的 Safari、Android 上的 Chrome、Googlebot（智慧型手機版與電腦版）、Bingbot、Facebook 與 X 的連結預覽機器人，以及 curl。
  • 自訂要求標頭：在每個躍點都會額外送出的標頭，例如用 Accept-Language: fr-FR 觸發依語言而定的重新導向。
  • Cookie：輸入 name=value; other=value，即可重現已登入、已表示同意或特定地區的狀態。重新導向鏈中設定的 Cookie 會像在瀏覽器中一樣，保留給後續躍點使用。
  • 用戶端重新導向：追蹤 meta refresh（HTML 自動重新整理）標記與簡單的 JavaScript 重新導向，或是只回報而不追蹤。
  • 忽略 SSL 錯誤：Cloudflare 邊緣網路一律會驗證憑證，因此這個選項無法略過有問題的憑證。TLS 錯誤會回報在發生錯誤的那個躍點上。

步驟 3：解讀結果

結果最上方會顯示最終網址及其狀態碼。下方的重新導向鏈每個躍點占一列，內容包括：

  • 要求的網址與使用的 HTTP 方法；
  • 狀態碼與原因短語（狀態碼參考指南逐一說明了每個狀態碼）；
  • 回應時間，也就是從送出要求到收到標頭為止的時間，包含 DNS 查詢與建立連線所需的時間；
  • 它所指向的 Location；
  • 回應標頭，以及該躍點所設定的 Cookie 名稱。

每次重新導向都會標示它的發生方式：HTTP 狀態碼、meta refresh（附上延遲秒數）或 JavaScript。已發現但未追蹤的用戶端重新導向也會一併回報。同樣重要的是，這次檢查是以什麼方式結束的：

結果 意義
最終回應 重新導向鏈抵達了不是重新導向的回應，例如 200 OK 或 404 Not Found。
重新導向迴圈 下一個要求會重複先前的某個要求：網址、方法和 Cookie 都相同。結果會顯示是哪個躍點讓迴圈閉合。
達到最大躍點數 到達上限時，重新導向鏈仍在繼續重新導向。結果會顯示下一個目標，但不會對它發出要求。
錯誤 某個躍點失敗，原因可能是 DNS、連線、TLS 或逾時，也可能是重新導向目標不是有效或允許的 URL。

警告會標示下列情況：重新導向鏈中有暫時重新導向、從 HTTPS 降級為 HTTP、超過三次重新導向、最終網址位於其他網域、有用戶端重新導向，以及無法讀取頁面主體的 HEAD 要求。

其中有一種警告需要特別留意。有些網站會對自動化或來自資料中心的流量顯示人機驗證（挑戰）頁面，例如 Cloudflare 的「Just a moment...」頁面。TrueURL 會標示看起來像這類頁面的回應，因為檢查只抵達了網站的防護層，而不是真正的目的地。真實的訪客最後可能會抵達別的地方。

如何用命令列檢查重新導向

macOS、Windows 10 和 11，以及大多數 Linux 發行版都已內建 curl。它會如實顯示伺服器送出的內容，完全不經過瀏覽器快取。以下範例使用 Unix shell；在 Windows PowerShell 5.1 中，請輸入 curl.exe，因為 curl 在那裡是 Invoke-WebRequest 的別名，並以 NUL 取代 /dev/null。

查看單一躍點

Bash
curl -I https://example.com/old-page

-I 會送出 HEAD 要求並印出回應標頭，包括狀態列，以及 Location（如果有的話）。除非另外指定，curl 不會追蹤重新導向。由於有些伺服器對 HEAD 的處理方式不同，如果結果看起來不太對勁，請改用 GET 再檢查一次；-o /dev/null 會捨棄回應主體，-D - 則會印出標頭：

Bash
curl -sS -o /dev/null -D - https://example.com/old-page

追蹤整條重新導向鏈

-L 會追蹤重新導向；搭配 -I 或 -D - 時，curl 會印出每個躍點的標頭。再用 grep 篩選，就能得到精簡的檢視結果：

Bash
curl -sIL http://example.com/Shoes | grep -iE '^(HTTP/|location:)'
HTTP/1.1 301 Moved Permanently
Location: https://example.com/Shoes
HTTP/2 301
location: https://www.example.com/Shoes
HTTP/2 302
location: /shoes/
HTTP/2 200

curl 預設最多追蹤 50 次重新導向；加上 --max-redirs 10，即可套用 Googlebot 的上限。

只印出最終網址

-w（write-out）選項會在傳輸結束後印出詳細資訊，讓 curl 變成一個輕巧的短網址還原工具：

Bash
curl -sSL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' https://example.com/go

%{url_effective} 是最後擷取的 URL，%{num_redirects} 是追蹤的重新導向次數，%{http_code} 則是最終狀態碼。%{time_redirect} 會回報在最終要求之前花在重新導向上的秒數。不加 -L 時，%{redirect_url} 會顯示第一次重新導向將會前往的位置。

測試 POST 要求

-d 會送出要求主體，並讓要求變成 POST。追蹤重新導向時，curl 的行為會和瀏覽器一樣：遇到 301、302 或 303 後改用 GET，遇到 307 或 308 則重新送出 POST 及其主體。

Bash
curl -sSL -o /dev/null -D - -d 'email=test%40example.com' https://example.com/subscribe

請避免同時使用 -X POST 和 -L。-X 會在每個要求上強制使用指定的方法，因此在 301、302 或 303 之後，瀏覽器會改用 GET，curl 卻仍持續送出 POST，結果測試到的是一條真實用戶端根本不會產生的重新導向鏈。

Bash
# 智慧型手機的 User-Agent
curl -sIL -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1' https://example.com/

# 額外的要求標頭
curl -sIL -H 'Accept-Language: de-DE,de;q=0.9' https://example.com/

# 送出 Cookie，並保留重新導向鏈中設定的 Cookie
curl -sSL -o /dev/null -D - -b 'consent=yes' -c cookies.txt https://example.com/

-A 用來設定 User-Agent，-H 用來新增標頭，-b 則用來送出 Cookie。-c 會將收到的 Cookie 儲存到檔案，並啟用 curl 的 Cookie 引擎，讓某個躍點設定的 Cookie 在下一個躍點送出。

curl 不會執行 JavaScript，也不會處理 meta refresh 標記。如果 curl 的最後一個回應是 200 OK 的 HTML 頁面，您的瀏覽器最後卻到了別的地方，就表示重新導向發生在用戶端。

如何用瀏覽器 DevTools 檢查重新導向

DevTools 會依照您自己的瀏覽器所見來顯示重新導向鏈，包含您的 Cookie、擴充功能和所在位置：

  1. 開啟 DevTools（按 F12，Mac 上則按 Cmd+Option+I），然後選取 Network（網路）分頁。
  2. 在 Chrome 和 Edge 中開啟 Preserve log（保留記錄），或在 Firefox 的網路設定選單中開啟 Persist Logs。否則每次載入頁面時，清單都會被清空，用戶端重新導向也會跟著從畫面上消失。
  3. 開啟 Disable cache（停用快取），以免快取的重新導向掩蓋伺服器目前實際送出的內容。
  4. 在網址列中輸入網址。

每個躍點都會以獨立的一列顯示，並附上 3xx 狀態碼；選取該列並開啟 Headers（標頭）分頁，即可查看 location 回應標頭。在 Chrome 中，如果 Size（大小）欄顯示「(disk cache)」或「(memory cache)」，就表示這次重新導向來自快取，而不是伺服器。

Chrome 有時會列出一個從 http:// 到 https:// 的 307 Internal Redirect。這並不是伺服器送出的，而是瀏覽器自行升級了要求，通常是因為它已經儲存了該網站的 HSTS（Strict-Transport-Security）政策。若要查看伺服器如何處理一般 HTTP 要求，請使用 curl 或 TrueURL。

常見的重新導向問題與修正方法

超過一個躍點的重新導向鏈

重新導向鏈是一層一層疊起來的：舊搬遷留下的規則指向某個網址，而這個網址在後來的搬遷中又被重新導向了一次。請讓每條規則直接指向最終目的地，並更新內部連結、canonical 標記、hreflang 註解和 Sitemap，讓自己的網站永遠不會觸發重新導向。批次重新導向檢查工具會列出哪些舊網址仍需要經過一個以上的躍點。

重新導向迴圈

Chrome 會將迴圈回報為「重新導向次數過多」（ERR_TOO_MANY_REDIRECTS），Firefox 則會顯示「The page isn't redirecting properly」（頁面未正確重新導向）。常見原因包括：

  • 位於代理伺服器或 CDN 後方的 HTTPS。 原始伺服器會將 HTTP 重新導向至 HTTPS，但代理伺服器是以一般 HTTP 連線到原始伺服器，所以原始伺服器永遠看不到 HTTPS，只會不斷重新導向。在 Cloudflare 上，這是 SSL/TLS 使用「彈性」（Flexible）模式時的典型結果；請改用「完整（嚴格）」（Full (strict)）模式，或讓原始伺服器檢查 X-Forwarded-Proto。
  • 兩個層級的規則互相衝突，例如 CDN 規則移除了 www，伺服器卻又把它加回去；或是框架加上了結尾斜線，CDN 卻將它去掉。
  • 依賴 Cookie 的重新導向。 登入頁或 Cookie 同意頁將訪客送回原本的網址，但由於 Cookie 沒有儲存下來，原本的網址又將訪客重新導向至登入頁。

重新導向迴圈檢查工具會顯示是哪個躍點讓迴圈閉合。接著，請讓每條規則只由一個層級負責。

同一條鏈中混用 301 和 302

先 301、再 302、最後 200 的重新導向鏈，代表永久搬移的中間夾了一個暫時的步驟。這通常是預設值造成的：除非另外指定，Express 的 res.redirect() 和 PHP 的 header('Location: ...') 都會送出 302。請在每個躍點都使用永久狀態碼，並用 301 重新導向檢查工具確認。我們的 HTTP 重新導向狀態碼指南說明了每個狀態碼適用的情況。

HTTP → HTTPS → www 的雙重躍點

非常常見的一條鏈是 http://example.com → https://example.com → https://www.example.com：明明一個躍點就夠，卻用了兩個。請將每個非標準的變體直接重新導向至最終的 HTTPS 網址，再用 HTTPS 重新導向檢查工具測試全部四種變體。

有一個例外是刻意為之的。如果您的標準主機是 www，又要將網域加入 HSTS 預先載入清單（preload list），hstspreload.org 會要求 http://example.com 先重新導向至 https://example.com，讓瀏覽器記錄根網域的 HSTS 政策。

結尾斜線不一致

/pricing 和 /pricing/ 是不同的網址。如果兩者都回傳 200 OK，就會產生重複內容；如果兩個層級把它們互相重新導向，就會形成迴圈。請選定一種形式，用一次 301 將另一種形式重新導向過去，並在連結中一致使用。網址結尾斜線檢查工具可以同時測試兩種形式。

僅在行動裝置發生的重新導向

獨立的行動版網站、應用程式安裝提示和裝置偵測，有時會將手機重新導向至別處，而且常常是導向行動版首頁，而不是對應的頁面。在行動裝置優先索引制度下，Google 主要使用智慧型手機檢索器進行檢索，因此對索引來說，行動裝置上的重新導向鏈最為重要。請用行動裝置與電腦重新導向比較工具比較兩者。

Sitemap 中的重新導向

Sitemap 應該列出您希望出現在搜尋結果中的標準網址，而這些網址都會回傳 200 OK。會重新導向的項目不但浪費檢索要求，還會傳遞互相矛盾的標準網址訊號。每次搬遷後，請執行 Sitemap 重新導向檢查工具，並將每個會重新導向的項目換成它的最終網址。

JavaScript 與 meta refresh 重新導向

Google 會將立即執行的 meta refresh 視為永久重新導向，有延遲的則視為暫時重新導向。至於 JavaScript 重新導向，Google 要等到轉譯網頁之後才看得到，而轉譯是在檢索之後才進行的步驟，也有可能失敗。許多其他爬蟲、連結預覽機器人和命令列工具完全不執行 JavaScript，有些甚至也會忽略 meta refresh。只要能控制伺服器，就請使用伺服器端重新導向，並用 Meta Refresh 重新導向檢查工具找出用戶端重新導向。

重新導向檢查清單

網站搬遷或變更 CDN 設定後，以及行銷活動上線前，請逐項確認這份清單：

  1. 每個舊網址都只經過一個躍點就抵達最終目的地。
  2. 永久搬移在每個躍點都使用 301 或 308。
  3. 四種通訊協定與主機變體最後都抵達標準的 HTTPS 網址。
  4. 沒有任何躍點從 HTTPS 降級為 HTTP。
  5. 查詢字串（包括 UTM 參數和聯盟行銷 ID）在整條重新導向鏈中都完整保留。
  6. 每個網址只採用一種結尾斜線形式，另一種形式則重新導向至該形式。
  7. 電腦、智慧型手機和 Googlebot 的要求最後都抵達對應的同等頁面。
  8. 盡可能以伺服器端重新導向取代 meta refresh 和 JavaScript 重新導向。
  9. 內部連結、canonical 標記、hreflang 和 Sitemap 都指向最終網址。
  10. 已移除且沒有替代內容的頁面回傳 404 或 410，而不是重新導向至首頁。
  11. 網站搬遷所設定的重新導向持續保留；Google 建議至少保留一年。