一位值班工程師打開供應商的網站，迎面是一個 reCAPTCHA。當時他的信箱和手機都在收告警。這道驗證要求他找出樓梯、紅綠燈和摩托車。他在 r/sysadmin 上寫道：「我正為一次緊急故障收著郵件和電話告警，你卻讓我花整整五分鐘點圖片？？？」
他的時機不太走運，但他的遭遇很常見。Cloudflare 營運著網路上規模最大的驗證網路之一，它給出的估算是，一道 CAPTCHA 平均要占用一個人 32 秒，而大約有 15% 的人會中途放棄。關於這些代價由誰承擔，W3C 的說法更重：這類互動任務本身「inherently excludes many people with disabilities, resulting in a denial of service to these users」（W3C）。
CAPTCHA 驗證是瀏覽器必須過的一道關卡，伺服器靠它決定要不要把你的請求當作人類發出的。它有三個部件：伺服器下發挑戰，瀏覽器作答，伺服器拍板。有意思的部分在拍板，因為在大多數現代網站上，被評分的根本不是那道題，而是你的工作階段。
這個落差解釋了 CAPTCHA 讓人惱火的大部分原因。一場從頭到尾都不考答案的測試，你沒辦法提前複習。下面講的是：這個縮寫是什麼意思、這套握手流程實際怎麼走、驗證為什麼會反覆回來，以及下一次被擋住時該做什麼。最後一部分我們會拿 Tabbit Browser 當例子，因為在這裡，AI 瀏覽器到底是什麼 比表面上看起來更要緊。
先說結論
CAPTCHA 是「Completely Automated Public Turing test to tell Computers and Humans Apart」的縮寫。這個名字描述的是一次反向圖靈測試：機器出題，然後指望自己也答不出來。
一次挑戰與回應驗證包含四個環節：下發、作答、權杖、校驗。權杖是一次性的，還有時效，所以重新整理頁面往往等於從頭再來。
現代系統大多在給風險打分，而不是批改一道題。reCAPTCHA v3 回傳 0.0 到 1.0 的分數，Cloudflare 也直說，勾選核取方塊這個動作本身不是訊號。
反覆出現的驗證通常能追到具體原因：時鐘或快取出錯、擴充功能攔住了驗證指令碼、虛擬私人網路出口、通行 cookie 過期。
按設計，CAPTCHA 對一部分身心障礙使用者就是一道屏障。W3C 稱之為拒絕服務，Cloudflare 自己的數字還顯示，音訊回退方案比沒用更糟：機器人比人解得還穩。
六種主要驗證類型一覽
你被要求做過的事，幾乎都能歸進下面六類。區別它們的不是那道題，而是你在操作的時候，伺服器真正在測量什麼。
| 驗證類型 | 你要做什麼 | 它實際測量什麼 | 它在哪裡失效 |
|---|---|---|---|
| 扭曲文字（經典款） | 輸入被扭曲的字母 | 光學字元辨識會不會失敗 | AI 連最難的一種變形都能以 99.8% 的準確率解出之後，Google 把它下線了 |
| 圖片網格（reCAPTCHA v2、hCaptcha） | 把所有含公車、樓梯、紅綠燈的格子選出來 | 在你點擊之前和點擊過程中蒐集的行為與環境資料 | 圖片模糊、邊界有歧義，而且不告訴你哪一格算對 |
| 核取方塊元件（reCAPTCHA v2、Turnstile Managed） | 勾選一個方框 | 瀏覽器特徵、原生 API，以及輕量的工作量證明 | 指令碼被攔截、快取不當或者系統時鐘漂移時會陷入迴圈 |
| 評分或隱形（reCAPTCHA v3、Turnstile Non-Interactive） | 介面上什麼都不用做 | 根據請求脈絡算出的風險評分 | 你永遠不知道分數為什麼低，怎麼處理由網站決定 |
| 工作量證明 | 等上幾秒 | 你的瀏覽器是否真的為一道題花掉了 CPU | 裝置慢就等得久，JavaScript 被攔截頁面就直接停住 |
| 隱私通行權杖 | 介面上什麼都不用做 | 是否有簽發方為你的裝置背書 | 只在支援該權杖的平台和瀏覽器上有效 |
把這張表再讀一遍，結論很清楚。六類裡只有兩類要求你做點聰明的事，其餘四類都只在旁邊觀察。
「CAPTCHA」這個縮寫到底是什麼
CAPTCHA 是一個刻意拼出來的縮寫：「Completely Automated Public Turing test to tell Computers and Humans Apart」。這個詞出自 2003 年的一篇論文，作者是卡內基美隆大學的 Luis von Ahn、Manuel Blum 和 Nicholas Hopper，以及 IBM Watson 的 John Langford，發表在 EUROCRYPT 上（Springer）。摘要裡一句話就說清了整個思路：「any program that has high success over a CAPTCHA can be used to solve an unsolved Artificial Intelligence (AI) problem.」
巧妙的地方在於角色反轉。圖靈測試問的是機器能不能冒充人類。CAPTCHA 把角色換了過來，讓機器當裁判，然後挑一件機器當時做不好的事。任何破解了它的機器人，按定義就等於解決了一個研究者還沒解決的問題。
這套設計注定會過時。一道題一旦對機器不再難，它就不再是 CAPTCHA，剩下的人只能繼續面對一道對機器已經不難、卻還要人類通過的題。Google 在 2014 年用大白話承認了這一點：「today's Artificial Intelligence technology can solve even the most difficult variant of distorted text at 99.8% accuracy. Thus distorted text, on its own, is no longer a dependable test」（Google Security Blog）。
挑戰與回應握手是怎麼走的
對完整流程講得最清楚的是 2005 年一篇 USENIX 論文，主題是防禦應用層拒絕服務攻擊，它描述的交換過程跟今天的元件用的是同一套（USENIX NSDI '05）。伺服器下發一道題，外加一個簽章權杖。你作答之後，伺服器先重新計算權杖雜湊，再檢查權杖是不是在四分鐘以內產生的，最後核對你的答案對不對。三項檢查都通過，它才會回傳一個有效期 30 分鐘的 cookie。
現代系統保留了這套結構，換掉了裡面的零件。Cloudflare 的 Turnstile 會注入一個名為 cf-turnstile-response 的權杖，由網站自己的後端來校驗，文件說得很明確：「A token can only be validated once, and a token cannot be redeemed twice」（Cloudflare）。
這個順序裡的三項檢查，解釋了日常挫敗感的一大部分。答案對了但權杖過期，失敗。cookie 沒能落到你的瀏覽器裡，失敗。驗證指令碼壓根沒跑起來，那就沒有權杖可校驗。這幾種結果長得一模一樣，你看到的還是同一個方框。
為什麼現代驗證很少要你解題
機器能認字母之後，整個產業把考試挪到了一個你沒辦法複習的地方：你的工作階段。Google 自己對回退何時出現的解釋是：「In cases when the risk analysis engine can't confidently predict whether a user is a human or an abusive agent, it will prompt a CAPTCHA to elicit more cues.」
reCAPTCHA v3 把這件事做成了 API。沒有介面元件，服務只回傳一個分數。Google 記錄的原文是「11 levels for scores with values ranging from 0.0 to 1.0」，其中 1.0 代表低風險，0.0 代表高風險（Google Cloud Fraud Defense）。除了分數，Google 還會給出 AUTOMATION、UNEXPECTED_ENVIRONMENT、TOO_MUCH_TRAFFIC、UNEXPECTED_USAGE_PATTERNS、LOW_CONFIDENCE_SCORE 這類原因代碼。它沒有公開的，只是這些代碼背後的完整訊號清單。
2026 年值得知道的一件事：developers.google.com/recaptcha 下的每個頁面現在都掛著一條棄用橫幅，指向 Google Cloud Fraud Defense。v3 模型正在被併入另一個產品面，Google 還提醒，一次接入在第一週測到的分數，跟長期生產環境裡的表現並不一樣。
Cloudflare 的 Turnstile 就核取方塊講了同樣的道理。它的元件有三種模式（Managed、Non-Interactive、Invisible），Managed 會根據訪客風險在核取方塊和靜默檢測之間選擇，產品說明也直說那個方框是幹什麼的：「the actual act of checking a box isn't important, it's the background data we're analyzing while the box is checked that matters」（Cloudflare）。
所以「圖片太模糊了」這個抱怨找錯了地方。模糊圖片只在風險引擎已經判定需要更多證據時才出現。
驗證為什麼會反覆回來
迴圈是有文件記錄的，並不神祕。Cloudflare 公開了自家元件的失敗代碼，包括 200100，對應「Clock or cache problem」，也就是時鐘不對或者挑戰被中間層快取了，還有 iframe 被攔截時的 200500（Cloudflare 錯誤代碼）。同一頁還把瀏覽器擴充功能列為原因之一：「Some browser extensions, such as ad blockers, may block the scripts Turnstile needs to operate.」
通行這一側有自己的計時器。cf_clearance cookie 證明訪客通過了驗證，「securely tied to the specific visitor and device it was issued to」，預設有效期 30 分鐘，另外還有「a few extra minutes to account for clock skew」。它還帶了一條比計時器更要緊的提醒：「The visitor may be re-challenged, even if the cookie has not expired」（Cloudflare）。
Google 給出的同類清單講的是網路，不是瀏覽器。它的說明文件列出了撞上「automated queries」這道牆的三類常見觸發條件：「a shared network that has been abused; your ISP may have recently assigned you a suspicious IP address; the site you're trying to visit may be under heavy attack right now」（Google FAQ）。這三件事都不是一道題能解決的，也都不是你的錯。
網路這一側的原因，也是虛擬私人網路常常變成 CAPTCHA 產生器的原因。Cloudflare 的觀察是，「privacy-focused users often ask their browsers to go beyond standard practices… changing their user-agent… and preventing third-party scripts from executing entirely」，這句話精確描述了一套加固過的設定在一場它從未被設計來通過的考試裡失敗。如果你想看單一廠商的詳細排查過程，我們的 Cloudflare 驗證迴圈指南 一步步走完了那個案例，為什麼隱私保護有時會弄壞網站 講的是更普遍的模式。
這些重複驗證還有一個安全代價，而且跟題目沒什麼關係。2026 年 8 月，一位管理員在一個小型企業網站上放了一個仿冒 reCAPTCHA 的東西，點擊之後會把一條 PowerShell 指令複製到剪貼簿。他要說的是疲勞，不是天真：「we and our staff are being so bombarded by these prove your human bots why wouldn't you click the do what it says」（r/sysadmin）。貼文最高讚的回覆點出了這個手法的名字，ClickFix，其他留言者則講了自家網路上的幾次險情。一堵所有人都被訓練成不讀內容就照做的驗證牆，本身就是個釣魚面。
CAPTCHA 解決不了的無障礙問題
W3C 在這件事上的措辭少見地直接。要求「users who are blind, visually impaired or dyslexic to identify textual characters in a distorted graphic is asking them to perform a task they are intrinsically least able to accomplish」（W3C）。同一份文件還記錄到，reCAPTCHA v2 的音訊替代方案有時乾脆不再提供，取而代之的是「Your computer or network may be sending automated queries」這個頁面。
WCAG 2.2 要求任何 CAPTCHA 都提供兩種不同模態，指南還特別說明，這項例外「applies only to the content of the CAPTCHA」，不包括它周圍的那張表單。它還承認了天花板：「Every type of CAPTCHA will be unsolvable by users with certain disabilities」（W3C WCAG 2.2）。
音訊回退並不像看上去那樣是張安全網。Cloudflare 測量過自家的音訊驗證，發現「only 31.2% of audio challenges resulting in a three-person agreement on what the correct solution actually is」，而「bots can accurately solve audio CAPTCHAs in over 85% of attempts」。當人類無法就答案達成一致而機器可以時，這個模態的方向就是反的。
社群回報和這項測量吻合。在 r/Blind 上，一位使用者描述了自己跟那個本該豁免螢幕閱讀器使用者的無障礙 cookie 奮鬥的過程：「Had a hell of a time getting their service to even allow that cookie to appear in my cookie jar when I checked the box… they have a separate option for a text-base captcha which is supposed to be more accessible but it was like trying to do a Caesar cipher in real time in your head」（r/Blind）。
一位開發者問該怎麼服務盲聾使用者。這些使用者使用點字顯示器，既看不見也聽不見驗證，他一句話說清了這個設計缺陷：「Traditional captcha fails because it assumes you can either see or hear」（r/webdev）。OWASP 的指南指向同一個方向，並附帶了自己的提醒，指出強制要求 JavaScript「will reduce the accessibility of the website, especially to visitors who use screen readers」，並建議優先採用多因素驗證，把 CAPTCHA 留給可疑或高風險的登入情境（OWASP）。
CAPTCHA 對 AI 代理做了什麼
這場軍備競賽有了新參與者。2025 年的一項基準測試 Open CaptchaWorld 用 20 種 CAPTCHA 測試多模態模型代理，報告稱「humans consistently achieve near-perfect scores, state-of-the-art MLLM agents struggle significantly, with success rates at most 40.0% by Browser-Use Openai-o3, far below human-level performance, 93.3%」（arXiv:2505.24878）。論文把這道驗證牆稱為「a critical bottleneck for deploying web agents in real-world applications」。
人們已經在繞開它了，有時候是把人類的那部分再交回給模型。一位使用者描述自己連續三次沒通過紅綠燈網格驗證，於是截了圖，把圖片貼進一個聊天模型，「told it to take over my computer and handle it」，結果第一次就通過了（X，@alt_w_v_g，597 likes）。一段講同樣煩惱的影片下面，有留言者點破了這個模式：「asking the actual robot to complete captcha instead of you is peak of irony and comedy」（YouTube，365 likes）。
驗證產業知道這一點。Cloudflare 應對代理流量的辦法是一套簽章方案，而不是把題出得更難：Web Bot Auth 使用 Ed25519 HTTP Message Signatures，再加一個公開的金鑰目錄，網站據此就能區分簽過名的代理和匿名指令碼（Cloudflare）。Visa 和 Mastercard 在 2025 年 10 月宣布了建立在其上的代理商務協定。經過驗證的機器人分類體系現在會把「Agent」和「Training」爬蟲分開。
對讀到這裡的人來說，方向比細節更重要。當代理能靠密碼學證明自己是誰，驗證牆就不再是一道技術測試，而成了一項政策決定：網站願意放哪些簽過名的代理進來。這個結局比一段模糊的樓梯圖片要好，不過它還剩一個問題沒解決：在還沒接入這套機制的網站上，代理式瀏覽器 依然會撞牆。
驗證擋住你時的一個實用選擇：Tabbit Browser
驗證把你卡住的時候，有三個問題決定你會卡多久：這是哪一類檢查、頁面到底在告訴你什麼、哪一條有文件記錄的原因符合你的環境。這三個問題都不需要你解題，需要的是閱讀和診斷，而這正是一個內建模型的瀏覽器能發揮作用的地方。
Tabbit Browser 是一款基於 Chromium 的瀏覽器，AI 層做在外殼裡，而不是當成擴充功能外掛上去。其中有三部分跟這裡相關。
第一，讀懂那堵牆。在 Tabbit 的 Omnibox 裡輸入 @ 就能把某個東西引用為脈絡：目前分頁、整個分頁群組、一張截圖、一個書籤，或者一個本機檔案。把它指向正在攔截你的頁面，問這是哪一類驗證、頁面上說了什麼。AI 讀的是你已經打開的那個頁面，你不需要把錯誤文字複製到另一個視窗。這一點對那些沒東西可複製的畫面尤其有用，比如只有一句「Performing security verification」，或者一段埋在主控台裡的 200100 代碼。
第二，把被攔住的東西和你手頭的事隔開。Tabbit 的 Agent Mode 會讓委派出去的任務跑在自己的分頁群組裡，所以一個要遍歷網站表單或後台的任務，不會接管你正在讀的頁面。委派任務進行到一半冒出驗證牆時，它出現在那個任務的群組裡。你回來自己完成需要人的那一步，你自己的分頁還停在原來的位置。
第三，把排查清單集中在一個地方做完，不用攤在五個排錯分頁裡。有文件記錄的原因數量有限，而且都可驗證：檢查系統時鐘，為這個網站關掉廣告和指令碼攔截，斷開虛擬私人網路，清掉這一個網域的 cookie，然後重新整理。配上一個能讀頁面的助手，這套流程花的是幾分鐘，而不是一個下午的瞎猜。
取捨是真實的，也值得直說。Tabbit 不會替你解 CAPTCHA，不會偽造瀏覽器指紋，也沒辦法讓一個信譽度低的 IP 位址看起來像住宅網路。如果你的出口 IP 在黑名單上，沒有哪個瀏覽器能修好，換網路或者聯絡網站。驗證牆的存在，是為了對你的工作階段做一個判斷。一個悄悄推翻這個判斷的瀏覽器是安全問題，算不上功能。如果某個網站的驗證你一次點擊就能過，誠實的答案是根本不需要工具。Tabbit 幫的是它周圍那部分：讀懂發生了什麼、讓你手頭的工作不受影響、把該做的檢查跑一遍。
如果真正反覆出問題的是瀏覽器這一層，那是另一個排查方向。瀏覽器更新為什麼會弄壞網站 和 擴充功能失效了怎麼辦 講的是相容性這一半，如果你在重新考慮整套工具，怎麼選對瀏覽器 講的是選購決策。
下次被驗證擋住時該做什麼
先把看到的現象對上原因，再動設定，不要隨手亂改。
| 你看到的現象 | 該怎麼做 | 原因 |
|---|---|---|
| 同一個網站反覆讓你驗證 | 檢查系統時鐘，為這個網站關掉指令碼攔截，然後只清掉這個網域的 cookie，再重新整理 | 有文件記錄的原因就是時鐘或快取漂移、驗證指令碼被攔截，以及沒有留存下來的通行 cookie |
| 隱私視窗裡能過，正常設定檔裡過不了 | 差異在某個擴充功能，或者你的設定檔裡存的網站資料 | 同一個瀏覽器、同一個網路，環境不同，所以問題出在本機 |
| 開著 VPN 時每個網站都要驗證 | 換出口節點，或者斷開 VPN 再測一次 | 資料中心位址區段自帶信譽記錄，任何瀏覽器設定都修不好 |
| 核取方塊變綠了，頁面重新整理後又變回空框 | 你的瀏覽器沒有保住通行 cookie | 權杖簽發之後被丟棄了，或者還沒過期網站就重新驗證了你 |
| 一個瀏覽器失敗，另一個能過 | 用能過的那個，同時把失敗情況回報給網站 | 單一瀏覽器失敗通常是設定檔層面的問題，不是網站層面的。見 Cloudflare 迴圈修復 |
| 你依賴螢幕閱讀器，而音訊回退也失敗 | 向網站要求非視覺的替代方案，並引用 WCAG | 兩種模態是硬性要求，而音訊那一種對人類來說可測量地不可靠 |
| 委派出去的代理任務撞上了牆 | 自己完成那一步，然後讓任務繼續 | 這次驗證要的是人，而面對一個沒簽名的代理，網站沒有別的辦法知道 |
| 你必須用的某個網站只在特定瀏覽器裡能用 | 先確認是瀏覽器的問題，還是入口網站的策略 | 有些網站是按瀏覽器偵測來放行，而不是按功能。見 為什麼就醫入口網站只在 Chrome 裡能用 |
簡短的回答
CAPTCHA 驗證不是對你的考試。它是關於你這次工作階段的一個風險判斷，披上謎題的外衣，讓這個判斷看起來像道有答案的題。這就是為什麼圖片常常看不清，也是為什麼迴圈的成因通常在環境，而不在能力。
所以要修的是環境，不是題。按順序把有文件記錄的原因走一遍：時鐘、擴充功能、網路、cookie。四項都試過之後驗證還在反覆，剩下的變數就是你位址的信譽，解法是換一條到網站的路徑，而不是換一個瀏覽器。
另外，當代理在幹活時，把需要人的那一步留給人。讓任務去做機械的部分，到了要證明你是你的那一刻，自己接手。把這兩件事分清楚的 AI 瀏覽器，在這裡比一個承諾偽裝得更好的瀏覽器有用。如果你早就跟這道題和解了，真正的問題是圍繞它的那個瀏覽器，那麼 這些才是要緊的特質。
裝上 Tabbit，把需要人的那一步留給人
Tabbit Browser 在 macOS 和 Windows 上免費，還能一步從 Chrome、Edge 或 Safari 匯入書籤、瀏覽紀錄、擴充功能和已儲存的密碼，所以試它不等於重建整套環境。安裝程式在 tabbit.ai/download。
安裝之前先把預期擺清楚。Tabbit 不會替你通過驗證，也不會假裝可以。在這個具體問題上，它給你的一個是能直接問「眼前這個頁面到底說了什麼」的地方，以及一套任務模型，讓委派出去的工作跑在自己的分頁群組裡，而不是壓在你的閱讀之上。其他一切仍然歸你，包括勾一個框然後繼續往下走這件事。
常見問題
用白話說，什麼是 CAPTCHA 驗證？
CAPTCHA 驗證是網站擋在你請求之前的一道步驟，用來判斷這次請求是人發的還是機器人發的。伺服器下發挑戰，你的瀏覽器作答，伺服器驗證一個簽章權杖，驗證通過才放行請求。在大多數現代網站上，真正被評估的是瀏覽器和網路訊號，跟那道題本身關係不大。
挑戰與回應機制到底是怎麼驗證我的？
伺服器把一道題或者一次看不見的檢測，連同簽章權杖一起發給你。瀏覽器把答案和權杖一起送回去，伺服器重新計算權杖雜湊，檢查權杖是否夠新，再核對答案。三項都通過，伺服器會下發一個短時效 cookie，在你後續的請求裡代表這次驗證結果。Cloudflare 的文件寫明，Turnstile 權杖只能驗證一次。
為什麼我在同一個網站上反覆遇到 CAPTCHA？
反覆出現驗證通常有具體原因，而不是針對你個人。Cloudflare 記錄了時鐘或快取問題、攔截驗證指令碼的擴充功能、虛擬私人網路出口這幾類原因，它發放的通行 cookie 預設有效期 30 分鐘，到期前也可能被重新驗證。Google 列出的是共用網路、你的網路服務商分配了一個可疑位址、目標網站正遭受大規模攻擊這三類觸發條件。
reCAPTCHA v2 和 v3 有什麼差別？
v2 會顯示一個核取方塊，必要時退回圖片驗證，v3 完全沒有介面元件，只回傳 0.0 到 1.0 之間的風險評分。Google 記錄了 11 個分數級距，以及 AUTOMATION、TOO_MUCH_TRAFFIC 這類原因代碼，但它沒有公開評分背後的完整訊號清單。v3 把放行還是拒絕的決定權交給網站，所以同一個分數在兩個網站上可能得到不同處理。
為什麼 CAPTCHA 對螢幕閱讀器和盲聾使用者是個難題？
W3C 把互動式 CAPTCHA 描述為對許多身心障礙使用者的一種拒絕服務，因為這道題本身就預設了你能看見或能聽見。WCAG 要求 CAPTCHA 提供兩種不同模態，同時也承認，任何類型的 CAPTCHA 都會讓某些使用者無法完成。Cloudflare 自己的測量顯示，人類在音訊驗證上就正確答案達成一致的比率只有 31.2%，而機器人在超過 85% 的嘗試裡都能解出音訊驗證。
AI 代理或者瀏覽器能替我解 CAPTCHA 嗎？
代理有時能通過，但並不可靠。2025 年的一項基準測試裡，表現最好的受測代理最多只通過了 40.0% 的驗證，而人類是 93.3%。用自動化手段解題，同時也會毀掉網站本來想拿到的那個訊號，機器人流量和合法的代理流量之所以會被混為一談，源頭就在這裡。一個聲稱能替你通過驗證的瀏覽器，值得警惕。