Cloudflare 出現重新導向次數過多怎麼辦？Too Many Redirects 排查指南

網站接上 Cloudflare 後，如果瀏覽器顯示「重新導向次數過多」、「頁面無法正常重新導向」或 ERR_TOO_MANY_REDIRECTS，通常不是網站檔案消失，而是瀏覽器、Cloudflare 與原始主機之間不斷互相轉址。

最常見的情況是：Cloudflare 使用 HTTP 連線到原始主機，但主機又強制轉成 HTTPS；Cloudflare 收到 HTTPS 後再次用 HTTP 回源，最後形成無限循環。

重新導向次數過多的常見症狀

• 網站開啟 Cloudflare 橘雲後突然無法進入。
• 瀏覽器顯示 ERR_TOO_MANY_REDIRECTS。
• HTTP 與 HTTPS 網址互相跳轉。
• www 與非 www 網址不停切換。
• 首頁可以開啟，但登入頁或後台無限轉址。
• 關閉 Cloudflare 代理後網站恢復正常。
• 清除瀏覽器 Cookie 後短暫正常，之後又出現錯誤。

這類問題通常和轉址規則、SSL 模式或網站程式對 HTTPS 的判斷有關，不一定是 Cloudflare 本身故障。

1）先檢查 Cloudflare SSL/TLS 模式

進入 Cloudflare 後台的 SSL/TLS 設定，可以看到常見的加密模式：

• 關閉：Cloudflare 不提供 HTTPS。
• Flexible：訪客到 Cloudflare 使用 HTTPS，但 Cloudflare 到原始主機使用 HTTP。
• Full：Cloudflare 到原始主機也使用 HTTPS，但不嚴格驗證憑證。
• Full (strict)：Cloudflare 使用 HTTPS 回源，並驗證原始主機憑證。

最容易造成無限重新導向的是 Flexible 模式。

例如原始主機有這條規則：

RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

訪客以 HTTPS 進入 Cloudflare，但 Flexible 模式會用 HTTP 連到原始主機。原始主機看到 HTTP 後，再要求轉成 HTTPS；Cloudflare 接著又用 HTTP 回源，最後形成循環。

2）確認原始主機是否真的有 SSL 憑證

切換成 Full 或 Full (strict) 前，要先確認原始主機可以直接接受 HTTPS 連線。

常見憑證來源包括：

• Let's Encrypt 憑證。
• cPanel AutoSSL。
• aaPanel 申請的 Let's Encrypt 憑證。
• 1Panel 申請或匯入的 SSL 憑證。
• Cloudflare Origin Certificate。

如果原始主機沒有憑證，卻直接使用 Full (strict)，可能會出現 526 Invalid SSL Certificate；使用 Full 時則可能出現 525 SSL Handshake Failed。

因此正確順序通常是：

1. 先在原始主機安裝有效 SSL 憑證。
2. 確認原始主機的 443 Port 可以正常連線。
3. 再將 Cloudflare 設為 Full (strict)。
4. 最後測試 HTTP 是否能正常轉到 HTTPS。

3）檢查 .htaccess 的 HTTPS 轉址規則

Apache 或 LiteSpeed 網站通常使用 .htaccess 執行 HTTPS 與 www 轉址。若規則重複或條件判斷錯誤，也會造成循環。

常見的 HTTPS 轉址規則：

RewriteEngine On

RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

接上 Cloudflare 後，部分主機可能需要判斷 Cloudflare 傳來的 X-Forwarded-Proto：

RewriteEngine On

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

不過不能在所有環境直接照抄，因為部分主機會同時提供 HTTPS 與 X-Forwarded-Proto。如果條件組合錯誤，反而可能造成新的轉址問題。

排查時可以先暫時註解 HTTPS 轉址規則，再重新測試。如果停止轉址後網站恢復，問題多半就在轉址條件。

4）檢查 www 與非 www 是否互相轉址

除了 HTTP 與 HTTPS，另一種常見循環是 www 與非 www 互相跳轉。

例如主機設定：

www.example.com → example.com

但 Cloudflare Redirect Rule 或網站程式又設定：

example.com → www.example.com

這樣兩邊會互相轉址，瀏覽器最後顯示重新導向次數過多。

應統一決定網站正式網址：

• https://example.com
• 或 https://www.example.com

然後確認以下位置使用同一方向：

• Cloudflare Redirect Rules。
• Cloudflare Bulk Redirects。
• .htaccess。
• Nginx 設定。
• 網站後台的網站網址。
• 程式內的固定網址。
• canonical 標籤。

5）檢查 Cloudflare 的 Always Use HTTPS

Cloudflare 的 Always Use HTTPS 會將所有 HTTP 請求轉成 HTTPS。這個功能本身通常不會造成問題，但如果主機、程式或其他規則也做了不同方向的轉址，就可能產生衝突。

常見重複設定位置包括：

• Cloudflare Always Use HTTPS。
• Cloudflare Redirect Rules。
• 主機控制面板的強制 HTTPS。
• .htaccess 的 301 規則。
• Nginx server 區塊。
• 網站程式內的 HTTPS 判斷。

建議只保留一個主要的 HTTPS 轉址來源，其他位置則配合相同設定，不要每一層都各自寫一套不同規則。

6）aaPanel 或 1Panel 要檢查哪些設定？

aaPanel 與 1Panel 通常以 Nginx、OpenResty 或其他 Web Server 提供網站服務。除了 Cloudflare 設定，還要檢查網站的反向代理與 HTTPS 設定。

常見問題包括：

• 網站設定中已啟用強制 HTTPS。
• Nginx 又寫了一組 HTTP 轉 HTTPS 規則。
• 反向代理後端仍回傳自己的 HTTPS 轉址。
• 應用程式沒有正確識別 X-Forwarded-Proto。
• 前端代理與後端服務的網址設定不一致。

Nginx 常見的 HTTP 轉 HTTPS 設定：

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://example.com$request_uri;
}

若 Cloudflare、Nginx 和網站程式同時執行不同方向的轉址，就需要統一正式網域與協定。

7）網站程式可能誤判為 HTTP

網站位於 Cloudflare 或反向代理後方時，實際訪客使用 HTTPS，但程式接收到的內部連線可能是 HTTP。

如果程式只判斷：

$_SERVER['HTTPS']

可能會誤以為訪客正在使用 HTTP，於是再次執行 HTTPS 轉址。

這類情況常見於：

• 舊版 PHP 系統。
• 自製登入系統。
• 後台固定要求 HTTPS。
• Laravel、CodeIgniter 或其他框架的代理設定不完整。
• 反向代理沒有被列入可信任代理。

程式通常還要正確判斷：

$_SERVER['HTTP_X_FORWARDED_PROTO']

不過這類標頭也不能在未限制代理來源的情況下完全信任，否則可能產生安全風險。應依網站架構與可信任代理設定處理。

8）為什麼清除 Cookie 後可能暫時正常？

重新導向問題有時與登入 Session、語系、購物車或後台 Cookie 有關。

例如：

• 登入 Cookie 綁定 www，但網站改成非 www。
• Cookie 設定為 Secure，但網站被誤判為 HTTP。
• 登入頁與首頁使用不同網域。
• 後台判斷未登入後轉到登入頁，登入頁又轉回後台。

可以使用無痕視窗測試，但清除 Cookie 只能確認問題是否與瀏覽器狀態有關，不能取代主機與程式設定修正。

9）用 curl 查看實際轉址路徑

瀏覽器只會顯示重新導向太多，但不容易看出每一次到底跳到哪裡。可以使用 curl 檢查回應標頭：

curl -I http://example.com
curl -I https://example.com
curl -I https://www.example.com

查看回應中的：

HTTP/2 301
location: https://example.com/

要追蹤完整轉址，可以使用：

curl -IL http://example.com

如果輸出中重複出現兩個網址互相切換，就能直接看出循環方向。

建議排查順序

1. 確認正式網址要使用 www 還是非 www。
2. 檢查 Cloudflare SSL/TLS 模式。
3. 確認原始主機有有效 SSL 憑證。
4. 檢查 Cloudflare Always Use HTTPS 與 Redirect Rules。
5. 檢查 .htaccess、Nginx 或控制面板的強制 HTTPS。
6. 使用 curl 查看完整轉址路徑。
7. 檢查網站程式是否正確識別 HTTPS 與反向代理。
8. 清除 Cloudflare 快取與瀏覽器 Cookie 後重新測試。

遇到無限重新導向時，不建議直接做的事

• 不要直接刪除所有 .htaccess 內容。
• 不要在沒有主機 SSL 的情況下亂切 Full (strict)。
• 不要同時在 Cloudflare、主機與程式加入不同方向的轉址。
• 不要只清除瀏覽器 Cookie 就認為問題已修好。
• 不要反覆切換 SSL 模式，卻沒有記錄每次設定。
• 不要為了暫時恢復網站而長期使用 Flexible 模式。