閱讀時間 12 分鐘
如何檢查網址轉址，並看懂重新導向鏈
一步步用 TrueURL、curl 與 DevTools 檢查網址轉址，看懂重新導向鏈的每個躍點，並找出及修正重新導向迴圈、過長的重新導向鏈與 301/302 混用等常見問題。
閱讀文章免費重新導向工具
HTTPS 重新導向檢查
輸入網域，測試使用者可能造訪它的四種方式：http 與 https，各自加上或不加 www。每一種都應該只經過一次永久重新導向，就抵達同一個 HTTPS 網址。
按 Enter 開始檢查
Cloudflare 邊緣網路一律會驗證憑證，因此這個選項無法略過驗證。憑證問題會顯示在檢查結果中。
隨第一個要求一起傳送，上限 16 KB。除非您另外設定 Content-Type 標頭，否則 JSON 內容會以 application/json 傳送，其他內容則以表單格式傳送。
1 至 50。瀏覽器最多只追蹤 20 次重新導向。
網站可能會對手機、爬蟲和連結預覽機器人採用不同的重新導向。
自訂要求標頭 0/20
會隨重新導向鏈中的每個要求一起傳送。
尚未新增自訂標頭。
填入值後才會傳送此標頭。標頭值不會儲存。
追蹤 HTML 網頁中的 <meta http-equiv="refresh"> 標記與 Refresh 標頭。
追蹤網頁指令碼中簡單、無條件的重新導向，例如 location.href = "…"。
設定會儲存在這個瀏覽器中。Cookie、標頭值和 POST 要求主體一律不會儲存。
HTTPS 檢查會測試哪些項目
TrueURL 會針對您輸入的主機建立四個起始網址，並逐一追蹤：
http://example.comhttp://www.example.comhttps://example.comhttps://www.example.com
在設定正確的情況下，這四個網址最後都會抵達同一個標準 HTTPS 網址。該版本會直接回應 200 OK，另外三個則透過單一 301 或 308 抵達。任何從 HTTPS 降回 HTTP 的躍點都會被標示出來。
TrueURL 也會檢查 HSTS：從最終的 HTTPS 回應（通常就是您的標準網址）讀取 Strict-Transport-Security 標頭，顯示原始值、max-age，以及是否設定了 includeSubDomains 與 preload。max-age 至少一年即為通過。max-age 較短、max-age=0、標頭中沒有有效的 max-age，或完全沒有這個標頭，都會顯示為警告。
常見的 HTTPS 重新導向問題與修正方式
- HTTP 沒有重新導向：http:// 版本直接顯示網頁，而沒有重新導向。請加上全站導向 HTTPS 的重新導向；單靠 canonical 標記無法保護訪客。
- 兩個以上的躍點：例如
http://example.com先到https://example.com，再到https://www.example.com。請合併通訊協定與主機規則，讓每個變體都直接導向最終網址（但請參閱下方的 HSTS 預先載入例外）。 - 暫時重新導向：從 HTTP 到 HTTPS 使用了 302 或 307。請改用 301 或 308，讓搜尋引擎只將 HTTPS 版本編入索引。
- HTTPS 降級：從 https:// 退回 http:// 的躍點，通常是多餘的規則所致，或是位於代理伺服器或 CDN 後方的應用程式以錯誤的通訊協定產生絕對網址。
- 憑證錯誤：某個變體（常見的是
www）不在憑證涵蓋範圍內。由於 Cloudflare 的邊緣網路一律會驗證憑證，該變體會顯示 TLS 錯誤，而不是重新導向。 - 變體結果不一致：
www與非 www 版本最後抵達不同的網址，導致訊號分散在兩個主機之間。
HSTS 與預先載入例外
HSTS 會告訴瀏覽器自動以 HTTPS 連線到您的網域，不必先發出 HTTP 要求。常見的標頭是 Strict-Transport-Security: max-age=31536000; includeSubDomains。瀏覽器只會在 HTTPS 回應中接受這個標頭，在一般的 HTTP 回應中則會忽略。
如果您想透過 hstspreload.org 將網域加入瀏覽器的 HSTS 預先載入清單，從 HTTP 出發的第一個躍點必須停留在同一個主機上：先從 http://example.com 到 https://example.com，之後才到 https://www.example.com。這種兩個躍點的重新導向鏈，是「只用一個躍點」原則中公認的例外。此外，標頭的 max-age 必須至少一年，並包含 includeSubDomains 和 preload，而且 HTTPS 重新導向本身也必須送出這個標頭。
改用 HTTPS 之後
- 將內部連結、canonical 標記、hreflang 註解和 Sitemap 更新為 HTTPS 網址，避免爬蟲一再碰到重新導向。
- 永久保留從 HTTP 到 HTTPS 的重新導向；舊連結在未來多年仍會指向 http://。
- 確認網站的 HTTPS 版本已在 Google Search Console 中完成驗證，並提交更新後的 Sitemap。
- 每次變更 CDN、主機代管服務或憑證後，都要再檢查一次。
相關指南
-
-
閱讀時間 13 分鐘
HTTP 重新導向狀態碼詳解：301、302、303、307、308 等
一次看懂每個 3xx 狀態碼的意義：從是否永久、要求方法、快取與 SEO 比較 301、302、303、307 和 308 轉址的差異，並附 nginx、Apache 與 PHP 設定範例。
閱讀文章
常見問題
如何確認 HTTP 是否轉址到 HTTPS？
在上方輸入您的網域。TrueURL 會要求 http:// 和 https:// 版本（包括有 www 和沒有 www 的版本），並顯示每個版本最後抵達哪裡、使用了哪些狀態碼，以及經過多少個躍點。當四個版本都抵達同一個 HTTPS 網址，而且每次重新導向都是永久性的，就代表設定正確。
網址應該使用 www 還是不帶 www？
就 SEO 而言，兩者都可以。重要的是選定其中一個，以 301 將另一個重新導向過去，並在連結、canonical 標記和 Sitemap 中一致使用。www 主機可能比較容易指向 CDN，因為 DNS 不允許在根網域上設定 CNAME 記錄（部分 DNS 供應商提供變通方式），但這是技術上的選擇，而不是排名因素。
為什麼 Chrome 開發人員工具顯示 HTTP 轉址到 HTTPS 是 307？
這個「307 Internal Redirect」是 Chrome 自己產生的，因為該網站在它的 HSTS 清單中，所以根本沒有透過 HTTP 送出任何要求。伺服器實際的重新導向可能是 301，也可能完全是別的狀態碼。TrueURL 沒有 HSTS 快取，因此一律會顯示伺服器實際的回應。
HTTP 以 302 轉址到 HTTPS 有問題嗎？
有一點小問題。訪客最後仍會抵達 HTTPS，但暫時重新導向會告訴搜尋引擎 HTTP 網址之後可能會恢復，這可能會拖慢改用 HTTPS 的過程或造成混淆。請改為 301 或 308。
如何確認網站是否有送出 HSTS？
在上方輸入您的網域，然後在結果中查看「HSTS 標頭」項目。TrueURL 會從最終的 HTTPS 回應讀取 Strict-Transport-Security 標頭，顯示它的值、max-age（少於一年時會顯示警告），以及是否設定了 includeSubDomains 與 preload。如果沒有這個標頭，每次從手動輸入網域或舊的 http:// 連結開始的造訪，第一個要求都是未加密的，同一個網路上的人可能會攔截它。有了這個標頭，看過它的瀏覽器下次就會直接使用 HTTPS。請先從較短的 max-age 開始，確認每個子網域都能透過 HTTPS 正常運作後再加上 includeSubDomains，然後將 max-age 提高到一年以上。
可以測試憑證無效或過期的網站嗎？
您會看到問題所在，但無法越過它繼續追蹤。即使開啟「忽略 SSL 錯誤」，Cloudflare 的邊緣網路也無法關閉憑證驗證，因此受影響的變體會在該躍點顯示 TLS 錯誤。反正這通常正是您需要知道的：瀏覽器在那裡也會向訪客顯示警告。