本篇文章更新時間：2026/03/30
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
ChatGPT 背後的驗證機制：Cloudflare 其實也在檢查你的 React 應用狀態
這篇文章揭露了 Cloudflare Turnstile 更深層的驗證邏輯，超越一般的瀏覽器指紋蒐集，甚至檢查你的 React app 是否真正被渲染。
本文整理自原文《ChatGPT Won't Let You Type Until Cloudflare Reads Your React State》(原文連結)，並加入我自己的理解與反思。
核心觀點 (Key Takeaways)
- Cloudflare Turnstile 不只是檢查瀏覽器，而是檢查 你是否真的載入並執行完整的 ChatGPT React SPA。
- 逆向顯示整個驗證程式包含 55 項指紋資料，涵蓋瀏覽器、Cloudflare 邊緣網路、及 ChatGPT 內部應用狀態。
- 所謂的「加密」其實只是 XOR，且金鑰直接藏在同一份 payload 裡，目的是阻止 casual inspection，而非阻止逆工程。
深入解析
作者從網路流量中解密 377 份 Cloudflare Turnstile 程式，發現它做的事情遠比一般 CAPTCHA 驗證複雜。最重要的發現是：這個驗證程式不只看你是不是用真實瀏覽器，而是檢查你是否真的載入了 ChatGPT 的 React app。
1. 兩層 XOR 加密，但金鑰就在 payload 裡
文章描述 Turnstile 的 bytecode 是兩層結構：
外層用 p token 當 XOR key，內層則用一個「由伺服器動態給出的 float」當 key。
也就是說，只要你有 HTTP 請求和回應的原始內容，就能完全解密整套指紋程式。這個設計顯然不是為了阻擋逆工程，而是為了降低靜態分析難度、讓代碼便於更新又不被立即看穿。
2. 程式收集 55 種指紋，分成三層
這是文章最具爆點的部分。我整理如下：
- 瀏覽器層（Browser）：WebGL、螢幕參數、字體測量、DOM 操作、localStorage
- Cloudflare 網路層（Edge Network）：cfIpCity、cfConnectingIp 等由 Cloudflare Edge 注入的 header
- 應用層（Application State）：
__reactRouterContext、loaderData、clientBootstrap
最後這個應用層是關鍵。這些資料只有在 ChatGPT 的 React SPA 已完成 hydration 時才存在。意思是：
模擬瀏覽器不夠，你必須能渲染 ChatGPT 本體。
3. Token 的構成：55 項資料經 JSON stringify、XOR、再包回去
最後的 token 其實只是 fingerprint JSON 再 XOR 的輸出，代表 token 本身並沒有不可逆的特性，因此：
Cloudflare 能夠還原所有指紋資料。
這讓人再次理解：加密不是阻隔，而是政策邊界。
筆者心得與啟發
我覺得這篇文章最大的意義，在於讓我們看到目前防機器人系統已經不只是看「你是不是一個真瀏覽器」，而是看「你是不是在真實環境中使用這個網站」。
這讓我想到現在越來越多平台出現「應用層反自動化」，例如：
- 必須執行特定框架的 hydration
- 必須載入真實的 Router 狀態
- 必須跑完 SPA lifecycle
換句話說，瀏覽器指紋已經不夠了。真正的戰場是在整個前端應用狀態本身。
另外我也注意到，作者逆向出的技術細節非常完整，尤其揭露 Turnstile 藉由 React Router 去檢查 hydration，我認為這會讓未來的 bot 開發者被迫「模擬整個前端 app」，成本大幅提升。
對一般使用者而言，這件事提醒我們：
- 反作弊與隱私保護永遠是拉鋸
- 加密不代表操作員看不到資料，只代表其他人看不到
而企業也會越來越依賴前端應用內部狀態來辨認真實使用者，這已經是一條不會回頭的路。
如果你想理解現代 bot detection 的複雜程度，我真心覺得原文值得一讀。它同時展示了工程技巧，也讓人看到網路驗證機制的下一個階段。