一、先把症狀分類：API 逾時不一定等於「被牆」
在診斷前，建議把現象寫成可觀測句子：是完全連不上、還是偶發重試後成功？回應本體是否曾出現 HTTP 401／403 之類的狀態碼？若錯誤訊息已明確指出金鑰、專案或額度，請優先回到帳戶與配額頁面處理，而不是盲目改規則。
當錯誤偏向 ETIMEDOUT、ECONNRESET、TLS 握手停滯，或只在特定網路環境（公司 VPN、家裡寬頻、雲端開發機）重演，才有較高機率與路由、DNS、出口品質、應用程式是否讀代理有關。 這也是為什麼「只教你在瀏覽器裝一個外掛」常常救不了 CLI：瀏覽器與終端行程各自擁有網路堆疊與環境變數，必須分開驗證。
二、你實際要對準哪些目的地？
雲端 API 客戶端通常不只有「一個固定 IP」：除主要 REST 主機外，還可能牽涉憑證鏈驗證、時間同步、套件下載與其他相依網域。 實務上會建議以官方文件與你實際錯誤截圖為準做白名單式收斂，而不是把整段網際網路都丟進同一個策略群組。
下面列出常見、「值得先納入思考」的方向（實際主機與路徑仍會依產品更新而調整）：對外提供模型的 HTTPS API 端點（例如許多使用者會接觸的 api.anthropic.com 類型主機名稱）、以及你所在工具鏈為了下載編譯資源或套件所連線的其他域名。 若你的組織使用私有映像站或離線套件庫，也請把這些例外寫進規則的上游或旁路，以避免誤把所有流量強制繞過內網資源。
三、在設定檔寫規則：讓 Anthropic API「明確可走 PROXY」
Clash 系列核心（包含社群常稱的 Mihomo／Meta 分支語境）強項在於以域名為中心的策略匹配：你可以為特定後綴建立乾淨的命中路徑，再把其餘流量交回 MATCH 的總兜底。
以下是一段示意性質的片段，請依你的訂閱、策略命名與公司政策調整（註解使用英文以利版本控管共識）：
# Example rules snippet — adapt group names / proxies to your profile
rules:
- DOMAIN-SUFFIX,anthropic.com,PROXY
- DOMAIN-SUFFIX,api.anthropic.com,PROXY
# Add other domains required by your toolchain after confirming in logs.
# ... your geo / private LAN rules ...
- MATCH,DIRECT幾個實務重點：不要把示意規則直接複製到生產環境而不檢查策略群組名稱；若你同時使用多個供應商，建議把不同服務拆到不同 proxy-group，方便在節點品質波動時只切換受影響的那一段；若有內網 API 閘道，請保留明確的 IP-CIDR 或域名例外，避免繞路造成延遲爆炸。
四、系統代理 vs. TUN：誰才真正覆蓋你的 CLI？
系統代理的好處是變更範圍相對可控：多數桌面應用在「願意遵守作業系統 HTTP(S) 代理設定」的前提下，會自動把流量送往本機監聽埠。 但 CLI 世界並非鐵板一塊：有些工具只吃環境變數、有些會讀設定檔、少數則完全自行解析 DNS 與 socket。
TUN模式則更接近「告訴作業系統：請把符合條件的封包先交給我」，由核心再依規則決定實際出站；對「不讀系統代理」的程式通常更友好，但你也必須接受驅動／權限／與其他 VPN 軟體互斥等成本。 在 Clash Verge Rev 內切換模式前，建議先備份原始網路設定，並在維護窗口演練「一鍵關閉 TUN、恢復直連」的還原路徑。
五、把環境變數對齊：讓 Claude Code 走同一條出口
即使圖形介面顯示「系統代理已開啟」，終端機裡的 Claude Code 仍可能因啟動方式不同而沒有繼承到變數。 常見做法是於互動式 shell 設定檔或專案啟動腳本中匯出 HTTPS_PROXY／HTTP_PROXY（實際鍵名請以工具文件為準），並確保所用埠與 Clash 監聽埠一致。
若你混用 SOCKS 與 HTTP 代理，請避免「以為設了其中一個就萬能」：某些函式庫預設只讀 HTTPS_PROXY，遇到 HTTP/2 或 gRPC 風格的通道時，錯誤訊息可能表現得像純粹的逾時。 這時候最有用的不是再加十條規則，而是用最小可重現的 curl 指令對照：同樣的域名在「顯式指定代理」與「依賴環境變數」兩種路徑下是否行為一致。
六、除錯清單：從 DNS 到日誌的順序感
建議固定一套「由近到遠」的順序，避免在還沒確認本機監聽是否正常前，就去懷疑遠端機房：
- 本機監聽與埠占用：確認 Clash 報告的混合埠或 SOCKS 埠未被其他程式占用，防火牆規則未攔截本機回環。
- DNS 污染或解析路徑：比較在直連與走節點時，同一主機名稱解析結果是否合理；若你啟用偽裝 DNS，請理解它與系統解析器之間的互動。
- 規則命中與策略群組：在圖形客戶端或日誌中檢視目標連線是否真的落在預設的 PROXY，或被意外的 GEOIP／關鍵字規則改寫。
- 單一節點品質：對雲端 API，短暫的卡頓有時來自隊列壅塞／上游封鎖而非你的設定錯誤；以另一組延遲穩定的節點交叉驗證最快。
- HTTP/3／QUIC 相關行為：在某些網路環境中，異常的傳輸層協定協商會表現為「偶發卡住」；若上游或本機有中間設備攔截，嘗試在客戶端或工具側關閉實驗性路徑（若可設定）並觀察差異——僅在你能判讀安全影響的前提下進行。
你也可以把問題濃縮成一段文字給同仁或社群：作業系統版本、代理模式（系統／TUN）、節點地區、失敗工具的版本、代表性的 curl 輸出——資訊越可重現，越不需要靠猜規則解題。
七、與「只解鎖網頁」教學的差異在哪？
大多數使用者第一次接觸 Clash 家族，會從瀏覽器解鎖影音或網頁卡頓開始；但開發者在雲端 API 場景面對的是長連線、重試語意、以及在 CI 與本地之間重現環境落差。 因此本文刻意把焦距放在：域名命中的可驗證性、出站策略對延遲的影響、以及終端程式的代理繼承路徑——這三者在 CLI 世界裡出現得更頻繁。
市面也存在許多強調「一鍵搞定」但透明度有限的商業加速器：短期看似省事，卻較難核對底層節點與紀錄留存策略；相較之下，圍繞開源核心＋可替換圖形殼的 Clash 生態，讓你能逐步把規則、日誌與還原步驟寫進內部維運文件，遇到 Anthropic API 這類延遲敏感的服務時，較容易定位是「規則沒打到」還是「節點本身壅塞」。若你正在尋找一條可以把圖形客戶端的易用性與核心的可觀測性結合在一起的路線，可先從本站 下載頁取得正式安裝包，再配合 教學做一次端對端演練，把系統代理、TUN 與命令列環境梳理到同一張架構圖上。
常見問題
Claude Code 走代理一定要開 TUN 嗎？
不一定。若你的命令列工具會讀取 HTTPS_PROXY 或 HTTP_PROXY，且僅需讓少數目的地走節點，系統代理搭配正確環境變數通常就足夠。TUN 適合想讓更多程式預設被接管的情境，但需額外權限與更完整的除錯計畫。
為什麼瀏覽器正常，但終端裡的 Claude Code 仍然逾時？
常見原因是終端行程沒有繼承到代理環境變數、或該工具使用自有網路堆疊而不理會系統代理。請比對同一台機器上以 curl 走代理與不走代理的差異，並檢查是否誤把只有瀏覽器擴充套件提供的代理當成系統層出口。
可以把 ANTHROPIC_BASE_URL 指到鏡像站嗎？
是否允許改用自訂基底網址，取決於你所使用產品的授權條款與公司政策。本文僅說明在本機網路層如何讓請求抵達官方主機；若你需要企業級部署，請與供應商或法遵團隊確認合規邊界。
規則命中了 PROXY，但日誌仍顯示連線失敗，下一步怎麼查？
先排除單一節點故障與 TLS 攔截：以另一條可用的代理或節點重試；再檢查本機時間、憑證與防火牆；最後對照核心的錯誤字串判斷是 DNS、握手還是上游阻斷。