金流成功但 WooCommerce 訂單沒更新？Cloudflare 設定檢查清單

你在 WooCommerce 後台看到一筆訂單狀態是「Pending Payment」，但金流商（綠界、LINE Pay、PayPal）的後台已經顯示這筆付款成功。客人跑來問你「我信用卡已經刷過了，為什麼訂單還是處理中？」你檢查金流外掛、重新更新訂單狀態後恢復正常，但同樣的情況每隔幾天就出現一次。

這種現象可能發生在金流外掛、主機防火牆、PHP 程式或 Cloudflare 任一層。只有 Security Events 顯示 callback 被 Challenge 或 Block，才能確認 Cloudflare 是斷點。

這篇從實際排查流程出發，教你用五個步驟確認 Cloudflare 的哪一層設定擋住了金流 callback，以及如何在不影響網站安全的前提下修正。如果你還不確定 Cloudflare 對 WooCommerce 有哪些常見的地雷，可以先看這篇：<a href="/blog/woocommerce-cloudflare-common-mistakes">WooCommerce 用 Cloudflare 免費版該避開的 5 個常見錯誤</a>。

先說結論

金流付款成功但 WooCommerce 訂單沒更新，代表「付款」與「訂單狀態更新」之間有一段失敗。Cloudflare 的 WAF 或 Security Level 是其中一種可能，不能在查日誌前直接下結論。

排查方向依序是：

確認斷點在 Cloudflare 層，而不是金流外掛或主機防火牆。
檢查 Cloudflare WAF Events 日誌，確認是否有金流 callback 被 Challenge 或 Block。
只對實際誤判的規則或安全產品建立最小 Skip。
確認 callback 路徑維持動態，但不要把 POST 失敗直接歸因於快取。
檢查 Security Level 與 Bot Fight Mode 是否對 callback 路徑造成干擾。

金流 callback 是怎麼被 Cloudflare 擋住的？

WooCommerce 的金流流程分兩段。第一段是客人在瀏覽器上填完信用卡資訊送出，金流商處理授權後在瀏覽器上顯示付款成功。第二段是金流商的伺服器從後端發送一個 HTTP POST 請求到你的 WooCommerce 網站，通知系統更新訂單狀態。這個第二段就是 callback。

第一段由瀏覽器操作，第二段是伺服器對伺服器的通訊，通常不會執行 JavaScript。若自訂規則、Security Level 或防機器人設定要求 callback 通過互動式 Challenge，金流伺服器就無法完成驗證。

當 Cloudflare 對 callback 路徑設定了需要執行 JavaScript 才能通過的安全檢查，金流伺服器不會執行 JavaScript，請求被卡在邊緣節點，永遠送不到你的 WooCommerce 主機。

Cloudflare 官方將 Skip 定位為處理合法流量被安全規則誤判的工具。使用前要先找到命中的規則，再決定要跳過 Managed Rules、Security Level 或其他特定產品，不是把 callback 路徑上的所有防護關掉。

第一步：付款成功但訂單沒更新，斷點在哪裡？

先記下測試訂單編號、付款時間、callback URL 與金流商回應，再對照四份紀錄：金流商通知紀錄、Cloudflare Security Events、主機 access log、WooCommerce／PHP log。若 Cloudflare 顯示 Block 或 Challenge，而且來源主機完全沒收到同一請求，斷點才在 Cloudflare。

不要在正式站直接切成 DNS Only 來猜原因。若必須做繞過 Cloudflare 的對照測試，應使用測試環境、限制來源 IP，並先確認 origin 不會因此暴露。測試完成後立即恢復原設定。

第二步：Cloudflare WAF Events 日誌怎麼查？

確認斷點在 Cloudflare 層後，下一步是查看 WAF Events 日誌。

進 Cloudflare 儀表板，點左側 Security > Events。這裡記錄了所有被 WAF 規則處理過的請求。時間範圍選在最近一次測試付款的時間前後，來源 IP 可以參考金流商技術文件提供的伺服器 IP 範圍。

常見的 WAF Events 類型：

Event 類型	代表意義
Managed Challenge	Cloudflare 要求請求通過 JS Challenge，但伺服器無法執行
JS Challenge	同上，較低層級的驗證
Block	WAF 規則直接封鎖請求
Rate Limit	短時間內請求次數超過限制

金流 callback 被擋時，WAF Events 通常會出現同一時間與來源的 Challenge 或 Block。如果完全找不到記錄，可能是金流商沒有送出、篩選條件不對、事件未被目前方案保留，或請求在其他層中斷。這時要比對金流商紀錄與 origin access log，不能直接判定是快取。

Cloudflare 官方說明：<a href="https://developers.cloudflare.com/waf/analytics/" target="_blank">WAF Analytics 查詢方式</a>。

需要注意的是，Cloudflare 儀表板只保留一段時間內的 Events 記錄。如果你在出問題當下沒有馬上查看，日誌可能已經被覆蓋。建議在測試付款前先清空 Events 篩選條件，測試後再回頭查。

第三步：金流 callback 路徑怎麼設 WAF Skip？

確認 WAF Events 有擋住 callback 之後，下一步是建立 WAF Skip 規則。

進 Cloudflare 儀表板，點 Security > WAF > Custom Rules，新增一條規則：

規則名稱填入「Payment Callback Skip」，方便日後辨識。
Field 選擇 URI Path，Operator 選擇「contains」。
Value 填入金流 callback 的路徑片段。

callback 路徑由金流外掛決定，同一家金流的不同外掛也可能使用不同 endpoint。請從外掛文件、實際網路請求或金流商後台取得完整 URL，不要直接複製網路上的路徑範例。

設定 Skip 時，只選擇 Security Events 顯示造成誤判的規則或產品，並保留 Log matching requests。Cloudflare 官方文件也指出，免費版 Bot Fight Mode 目前不能被 Skip；若確認是它誤擋，只能重新評估是否關閉該功能或調整架構。

Cloudflare 官方說明：<a href="https://developers.cloudflare.com/waf/custom-rules/skip/" target="_blank">WAF Skip 規則設定</a>。

設定完成後，用金流商提供的測試環境重新建立一筆完整交易；若金流商後台確實提供測試通知重送功能，也可以依其文件操作。不要把手動修改 WooCommerce 訂單狀態當成 callback 已修復的證明。

第四步：callback 路徑需要設 Bypass Cache 嗎？

Cloudflare 預設主要快取 GET 與 HEAD，金流 callback 常用的 POST 通常不會成為邊緣快取內容。因此，POST callback 失敗時，快取不是第一個排查方向。

檢查方式：回到 Cloudflare 儀表板，點 Cache > Cache Rules，使用前面從外掛文件與日誌確認的實際 callback 路徑。若它被自訂 Cache Everything 規則涵蓋，就為該精確路徑建立 Bypass；不要為了方便而把整個 WooCommerce REST API 都排除或放寬安全防護。

仍建議把 callback、購物車與結帳路徑設為 Bypass，避免外掛同一路徑上的 GET 回應或錯誤頁被不當快取。這是防禦性設定，不代表它能修好 WAF、PHP 或外掛層的錯誤。

第五步：Security Level 與 Bot Fight Mode 怎麼設才安全？

Security Level 設得較嚴格，或網站開啟 I'm Under Attack Mode 時，合法的自動化請求也可能被要求通過 Challenge。若 Security Events 證明 callback 命中這類檢查，再對精確路徑做最小調整。

Bot Fight Mode 可能把 server-to-server 請求判成自動化流量，但要以事件與對照測試確認。

比較安全的作法是只跳過造成誤判的 Security Level、Managed Rule 或 Rate Limiting，並限制 HTTP method、精確路徑及可信來源。免費版 Bot Fight Mode 不能用 Skip 排除，不能把這兩種機制混為一談。

Cloudflare 官方說明：<a href="https://developers.cloudflare.com/waf/troubleshooting/" target="_blank">WAF Troubleshooting</a>。

以上都正常但問題還在，接下來查什麼？

如果以上五個步驟都確認沒有問題，但有時還是會發生金流成功但訂單沒更新的情況，還有幾個方向可以查：

金流外掛的 API 設定是否正確。API 金鑰、商店代碼、return URL 與 notify URL 的值是否跟金流商後台一致。多數金流外掛的設定頁面會顯示這些值，直接複製到金流商後台比對。
主機層的防火牆是否擋住 POST 請求。有些主機商會擋掉來自特定國家 IP 的 POST 請求。檢查主機的 mod_security 或 WAF 規則，把金流商的伺服器 IP 加入白名單。
金流外掛版本與 WooCommerce 版本的相容性。如果 WooCommerce 最近升級過，金流外掛可能還沒有完整支援新版。查看外掛的更新記錄或 changelog。
網站的 PHP error log。WooCommerce 的 callback 處理過程若發生 PHP 錯誤，訂單狀態就不會更新。請從主機控制台、容器 log 或在受控測試期間啟用 WordPress debug log 查詢，不要把錯誤直接顯示給前台訪客。

若問題是特定台灣金流的參數或通知驗證，可以接著看<a href="/blog/wordpress-woocommerce-ecpay">WordPress 串接綠界與 callback 排錯</a>；準備重新檢查整套金流設定時，則參考<a href="/blog/taiwan-wordpress-payment-setup-guide">WooCommerce 台灣金流物流設定指南</a>。

常見問題

關掉 Cloudflare Proxy 就正常，可以一直保持 DNS Only 嗎？

A: 可以暫時當作解決方案，但不建議長期這樣做。關閉 Proxy 代表網站 IP 位址直接暴露，DDoS 防護與 CDN 加速效果都會消失。正確作法是找出 Cloudflare 哪一層設定擋住 callback，針對那個路徑做精準修正，而不是整個關掉防護。

金流 callback 路徑不只一個，要全部設 WAF Skip 嗎？

A: 不一定。只有被 Cloudflare 規則誤判的實際路徑才需要 Skip。不同外掛的路徑、驗證方法與來源 IP 都不同，請逐一依文件與日誌設定。

WAF Skip 會不會讓網站不安全？

A: 會降低該路徑被跳過項目的防護，所以規則必須最小化。至少限制精確路徑與 POST method，來源 IP 穩定時加 allow 條件，應用程式端仍要驗證金流簽章、訂單金額與交易編號，並保留重放攻擊防護。

主機防火牆也會擋 callback，要怎麼確認？

A: 請主機商提供伺服器的 access log，搜尋金流商的 IP 是否有抵達主機的記錄。如果 Cloudflare WAF Events 沒有擋住記錄（代表請求已經通過 Cloudflare），但 access log 也沒有記錄，代表請求被主機層的防火牆擋住。如果 access log 有記錄但 WooCommerce 訂單狀態沒更新，問題出在 PHP 或外掛層。

設定完要怎麼確認真的修好了？

A: 做一次完整的測試付款流程。用金流商提供的測試環境（綠界測試碼、LINE Pay sandbox）走完一次結帳，付款完成後回到 WooCommerce 後台確認訂單狀態是否正確更新為 Processing 或 Completed。同時回頭檢查 Cloudflare WAF Events，確認 callback 請求的狀態是 Skip，不是 Challenge 或 Block。

官方參考資料

<a href="https://developers.cloudflare.com/waf/custom-rules/skip/" target="_blank">Cloudflare WAF Skip 規則設定</a>
<a href="https://developers.cloudflare.com/waf/custom-rules/skip/options/" target="_blank">Cloudflare WAF 可跳過項目與限制</a>
<a href="https://developers.cloudflare.com/cache/how-to/cache-rules/settings/" target="_blank">Cloudflare Cache Rules 設定</a>
<a href="https://developers.cloudflare.com/waf/analytics/" target="_blank">Cloudflare WAF Analytics 查詢</a>
<a href="https://woocommerce.com/document/payment-gateway-api/" target="_blank">WooCommerce Payment Gateway API</a>