2026 年 Agentic AI 熱度持續升溫，Claude Code 與 Claude Opus 4.7 成為許多開發者的新選擇；不少人也在比較 Claude Code 與 Cursor 哪個更適合自己的流程。 然而一旦進入實際開發，最先卡住的往往不是模型能力，而是Anthropic API 逾時、npm install 卡住，或終端機裡的 Claude Code CLI 顯示連線失敗。 這篇文章以 Clash Verge Rev 為客戶端，示範如何把「API 呼叫」「套件下載」「GitHub 依賴」拆成可維護的代理分流與除錯路徑；若你尚未完成基礎安裝，可先閱讀 Clash Verge Rev Windows 完整設定教學 建立訂閱與基礎模式，再回到本文處理 Anthropic 開發情境。

Anthropic 產品與 API 端點會隨版本更新而調整，實際網域請以當下官方文件為準。本文著重在Clash 規則思維、TUN 與環境變數如何配合 Claude Code 開發流程，而非替換任何服務條款或安全建議；API 金鑰請妥善保管，勿寫入公開設定檔。

一、先釐清「Claude Code 流量地圖」

要把 Clash 規則寫得可預測，第一步是接受一件事：AI 開發不是單一網址。 你在瀏覽器開啟的 Anthropic 主控台與說明文件會再拉一組靜態資源與身分驗證相關網域；終端機裡的 Claude Code 會對 api.anthropic.com 等端點發起 HTTPS 請求，且可能維持長時間串流；同時 npm 會連向 registry.npmjs.org 下載套件，許多專案還會從 GitHub 拉取原始碼或二進位資產。 若你把所有流量都丟進同一個「慢節點」或「全部 DIRECT」，就很容易出現「主控台能開，但 Claude Code 一直轉圈」或「npm 顯示 ETIMEDOUT 但其實是 DNS 先失敗」的假象。

建議你用一張紙或筆記本列出四類目標：人類瀏覽的介面（主控台、docs.anthropic.com）、程式化的 API（api.anthropic.com 及相關子網域）、套件生態（npm registry、可選的 GitHub raw 與 release 資產），以及 Claude Code 自身更新可能觸及的 CDN 或安裝來源。 每列一項就問自己兩句話：這條連線在作業系統裡是誰發起的？它會不會自動繼承瀏覽器的系統代理？ 這兩句話答不出來，後面再怎麼調逾時秒數都只是在賭運氣——尤其在切換到 Claude Opus 4.7 這類回應較長的模型時，不穩定的出口會被放大成「模型不可用」的錯覺。

二、為什麼用 Clash Verge Rev 做「可觀測的分流」

Clash 系譜的核心價值在於規則引擎與政策組：你可以先決定哪些網域必須命中哪個出站，再把「實驗性節點」「常用落地」與「僅供瀏覽」拆開。 Clash Verge Rev 則把圖形介面、設定同步與本機檔案路徑收斂到對桌面使用者友善的型態，對需要長期維護多份設定、或要在公司與家中切換環境的開發者來說，成本通常低於只靠作業系統內建代理。 對 Claude Code 這類會同時碰到瀏覽器、Node 執行環境、npm CLI 的工具鏈，你最需要的是可重複的命中紀錄：哪個請求被哪條規則接走、是不是意外用了 DIRECT、是否有 TLS 握手失敗。沒有這些資訊，你只能不斷在終端機裡按重新執行。

實務上我會建議你把規則寫成「由窄到寬」：先為已知的 api.anthropic.com 寫 DOMAIN，再以 DOMAIN-SUFFIX,anthropic.com 接住主控台與文件，對 npm 則單獨處理 registry.npmjs.org 與 npmjs.com，最後才落到地區或預設政策。 這樣當 Anthropic 因新子網域載入失敗時，你可以很快從記錄中抄到新主機名，而不是整包規則打掉重寫。 若你目前完全沒有規則習慣，也不要急著複製一整份社群大全；先讓API 端點與 npm registry穩定，再擴充分流到 GitHub 與其他 CDN。

三、Anthropic API 與主控台：常見網域與規則思路

Anthropic 開發者流量主要集中在 api.anthropic.com——這是 Claude Code 與各語言 SDK 呼叫模型的核心端點；瀏覽器端的 console.anthropic.com、claude.ai 與 docs.anthropic.com 則服務於金鑰管理、對話介面與文件閱讀。 實際清單會隨產品改版而變化，因此本文刻意不給一份「永久有效」的黑名單式列表，而是提供可遷移的判斷方式：當你看到 Claude Code 報錯，請優先到 Clash 的連線紀錄找出失敗或極慢的目標，再回頭補規則。

撰寫規則時請注意政策組的頻寬與延遲：API 串流會維持長連線，若你把 api.anthropic.com 指到一個過載或對 HTTP/2 相容性差的節點，終端機不一定立刻報錯，但會讓你誤以為 Claude Opus 4.7「變慢」或「斷流」。 較務實的做法是讓「API 流量」走延遲穩定、支援長連線的出口，把高頻 npm 下載放到另一組政策組；這在企業網路與家用網路切換時尤其有感。 若你使用公司提供的分裂 DNS，也要同步檢查 Clash 的 DNS 設定是否與內網解析衝突，避免解析到錯誤位址後又被防火牆擋回。

以下為示意規則片段，請將 ANTHROPIC_API、NPM_REGISTRY、DEV_PROXY 替換為你訂閱中的政策組名稱（例如「香港自動」「美國專線」等）： 

# Illustrative rules — adapt policy names to your profile
DOMAIN-SUFFIX,api.anthropic.com,ANTHROPIC_API
DOMAIN-SUFFIX,console.anthropic.com,ANTHROPIC_API
DOMAIN-SUFFIX,claude.ai,ANTHROPIC_API
DOMAIN-SUFFIX,registry.npmjs.org,NPM_REGISTRY
DOMAIN-SUFFIX,github.com,DEV_PROXY
DOMAIN-SUFFIX,objects.githubusercontent.com,DEV_PROXY

不建議把 anthropic.com 與整個 npmjs.org 樹狀網域粗暴合併到同一「國外自動」組而不查記錄： npm 安裝大型依賴時可能占滿上行，反而讓並行的 Anthropic 串流回應排隊。 較穩妥的做法是：API 走低延遲組，npm／GitHub 走高頻寬組，本機 127.0.0.1 與 RFC1918 網段直連。

請勿把 ANTHROPIC_API_KEY 或長效憑證貼在部落格留言或公開設定檔。代理只解決連線路徑，不解決身分與配額邊界；實驗建議限縮在測試金鑰與最小權限原則。

四、npm 與 GitHub：別讓套件下載拖垮整個環境

許多人在排查 Claude Code 時忽略了 npm：安裝 CLI、初始化專案或拉取 Anthropic 官方 SDK 時，終端機會對 registry.npmjs.org 發起大量並行請求。 若規則未命中或誤走 DIRECT，常見症狀是 npm ERR! code ETIMEDOUT 或 registry 連線被重設；這與 API 逾時無關，卻會讓你以為「整個 Anthropic 生態都連不上」。 建議為 npm 相關網域單獨建立規則，並在 Clash 記錄中確認 tarball 下載是否穩定命中預期節點。

GitHub（github.com、raw.githubusercontent.com、objects.githubusercontent.com）則常出現在依賴安裝、npx 拉取或 Claude Code 外掛更新流程中。 若你的訂閱規則對 GitHub 採 DIRECT 而本地 ISP 對該路徑不穩，就會出現「瀏覽器能開 GitHub 網頁，但 CLI 下載失敗」的分裂現象——原因仍是不同行程、不同代理路徑。 實務上可為 GitHub 相關後缀建立獨立規則，或確保 TUN 模式下 CLI 流量一併經過 Clash 判斷。

五、系統代理與 TUN：什麼時候要開哪一個

系統代理的好處是設定直覺：瀏覽器與部分應用程式會自動遵從作業系統的 HTTP 代理設定。 對於只在 Chrome 或 Edge 操作 Anthropic 主控台的使用者，系統代理常常就夠用，只要你在 Clash Verge Rev 裡確認系統代理開關與埠號一致即可。 然而 Claude Code CLI、npm、Node 子行程與某些語言執行環境，都可能在「瀏覽器已通、終端機仍斷」的狀態下讓你困惑——它們未必會自動繼承系統代理。

TUN 模式則透過虛擬網路卡把系統層流量交給 Clash 判斷，對「不吃系統代理」的行程覆蓋率較高，也比較容易讓本機多個工具在同一份規則下行為一致。 代價是需要驅動與較高權限，部分企業筆電或受管理裝置會限制安裝；若你先前在 Windows 教學 已為 Wintun 與第一次啟動踩過權限流程，延續到 Claude Code 情境通常較順。 實務上我會建議先系統代理驗證規則命中，再在 CLI 或 npm 仍逾時時啟用 TUN 作為第二道手段，而不是一開始就全部依賴 TUN。

六、HTTP_PROXY、HTTPS_PROXY 與 npm 代理設定

就算 TUN 開著，有些工具仍會對代理行為有特殊設定；為終端機顯式指定 HTTPS_PROXY 與 HTTP_PROXY 仍是 Anthropic 開發者最常備的逃生梯。 請以 Clash Verge Rev 介面顯示的本機埠為準，常見寫法是將代理指到 127.0.0.1 加上對應埠號，協定需與你的工具支援一致。 npm 另可透過 npm config set proxy 與 npm config set https-proxy 設定，但與環境變數並存時請避免重複指向不同埠造成迴圈。

NO_PROXY 的重要性常被低估：一旦你把整機流量導向代理，但某個本機 MCP 服務或內網 registry 其實應該直連，就會出現雙重代理或無效閘道。 建議你把本機回呼位址、內網網段、公司內部網域名列入排除，並在切換網路環境時重新檢查這份清單。 Windows 與 macOS 對環境變數大小寫與逗號格式的細節略有差異，若你是在整合式終端機與系統終端機之間切換，也要確認兩邊載入的設定檔一致。 

# Example only — replace port with your Clash Verge Rev mixed/HTTP port
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

# npm optional (same port as above)
npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

上面片段僅示意結構，真正可用的埠號請你在應用程式內核對；不同版本預設可能不同，照抄網路文章數字是逾時排查裡最常見的冤枉路。

七、Claude Code 實測：從最小請求到 Opus 4.7 長對話

在代理規則就緒後，建議用由小到大的方式驗證，而不是一上來就跑大型 Agent 任務。 第一步，用 curl 對 api.anthropic.com 發送最小 HEAD 或 GET（需注意 API 金鑰與官方允許的探測方式），確認 TLS 握手與路由無異常。 第二步，執行 Claude Code 的簡短指令或單輪對話，觀察 Clash 記錄中該連線是否穩定命中預期規則。 第三步，再切換到 Claude Opus 4.7 或較長 context 的任務，此時若出現中斷，優先檢查是否為串流被節點重置，而非 API 金鑰失效。

若你同時在使用 Cursor 等其他 AI 編輯器，請記得它們可能走不同的 API 端點或本機代理設定；Claude Code 與 Cursor 並存時，規則衝突較少見，但環境變數與 TUN 覆蓋範圍仍可能互相影響。 把兩套工具各自「誰發起請求、走哪條路」寫清楚，比盲目關閉其中一個更有助於長期維護。 對 API 層的速率限制與退避也要有所預期：雲端端的 429 有時會表現得像網路不穩，若你同時開多個 Claude Code 工作階段又跑 npm 大量安裝，觀察到的錯誤訊息可能混雜多種來源。

八、連線穩定：DNS、TLS 與逾時的檢查清單

Claude Code 連線問題往往呈現為終端機上的逾時或中斷，但根因可能落在四個彼此不相干的層次：DNS、TCP、TLS、或應用層重新導向。 在 Clash 分流已啟用的前提下，我建議你固定用以下順序自我掃描。 第一，確認 api.anthropic.com 的解析結果是否與預期一致，會不會被公司 DNS 劫持到錯誤入口。 第二，在 Clash 記錄觀察該連線是否反覆重試、RST、或握手逾時，並對照你是否最近換了出口節點。 第三，檢查 API 金鑰、組織配額與模型名稱是否正確——代理無法修復 401 或 403。 第四，才考慮在工具端調整逾時時間；若根因是規則誤匹配，把逾時調再大也只是把失敗變慢而已。

對 npm 逾時，則額外檢查 registry 鏡像設定是否與代理衝突：有些團隊會改用私有 registry，若 NO_PROXY 未包含該主機名，請求可能被錯誤地送到 Clash 再轉發而失敗。 把代理出口穩定下來後，若仍遇到可重現的錯誤代碼，再回頭查詢 npm 或 Anthropic 官方狀態頁，比盲目更換規則有效。

九、把「可觀測」變成習慣：除錯不露死角

成熟的排錯流程其實只有一句話：每一次變更都要能對應到一條紀錄或一個度量。 當你為 Claude Code 新增一條 Anthropic 規則，請同步在 Clash 端確認新規則的優先順序不會被更寬鬆的規則蓋過；當你更新 npm 或 Node 版本，請在終端機用 npm ping 或最小安裝驗證網路仍可達，而不是只靠 Claude Code 重新執行。 若你與同事共用一份訂閱備份，也要約定「誰的版本負責接住哪些開發網域」，避免兩份規則各自漏寫一半，整合時才爆發問題。

最後補一點與心態有關的現實：Anthropic 與 npm 生態都是會變動的系統，今天能用的規則明天可能因 CDN 或端點調整而需要補一行網域。 把本文的地圖思維保留下來，比儲存一份靜態 YAML 更有長期價值。 當你能清楚描述「哪個行程、對哪個主機、在什麼模式下應該命中哪條規則」，Claude Code 的開發過程就不會被連線噪音淹沒，你也更容易把注意力放回 Agent 邏輯與實際程式碼產出。

十、常見問題（精簡版）

Q：主控台能開，但 Claude Code 仍報 API 錯誤？

瀏覽器與 CLI 常走不同代理路徑；請檢查環境變數、TUN，以及 api.anthropic.com 是否在 Clash 記錄中被誤判為 DIRECT。 也請確認 API 金鑰已正確匯出到目前 Shell session。

Q：我應該把所有 anthropic 子網域都指到同一節點嗎？

不一定。過度集中可能拖慢主控台載入；較務實是讓 API 端點走穩定出口，瀏覽介面可依延遲再拆分。 關鍵仍是觀察記錄並避免慢節點成為單一故障點。

Q：Claude Code 一定要啟用 TUN 嗎？

不一定。若 CLI 已正確使用系統代理或環境變數，系統代理可能就夠。 TUN 是在「工具不吃代理」時提高覆蓋率的手段，而不是儀式開關。

Q：公司網路攔截 HTTPS 時怎麼辦？

企業中間盒會導致 TLS 錯誤或憑證不信任，這與 Clash 規則是否命中無關。 需要依公司 IT 指引安裝信任鏈或改用核准的出口，並避免在不可信網路繞過安全控制。

十一、可複製帶走的檢查清單

當你把 Claude Code、Anthropic API 與 npm 放在同一張流量地圖上，Clash Verge Rev 就不再只是「能連上網的開關」，而是讓 Agentic 開發反覆實測仍可預期的基礎設施。 把規則、模式與環境變數三劍合在一齊，你就能把時間花在 Claude Opus 4.7 與程式邏輯本身，而不是連線表層的無限重試。