📖 教學 ⏱ 約 24 分鐘閱讀

JetBrains Junie CLI 公測：用 Clash Verge Rev 給終端 Agent 做 API 分流與 DNS 實測（2026）

JetBrains在 2026 年讓Junie CLI進入公開測試：它不是在 IDE 視窗裡多一個附屬面板，而是把終端機 Coding Agent當成可長駐、可 headless 的工作單元——從安裝腳本、說明站、權杖頁到互動式指令列，網路形狀會同時混到「下載配送」「帳戶登入」「雲端協調」與（你若啟用 BYOK）各家模型 API。這種多段出口並行對一般「能開網頁就好」的代理判準特別不友善：API 分流只要有一個子網域在訂閱檔前半段被錯送，症狀就會變成登入轉圈、授權失敗或看似隨機的逾時。本文把介面收斂在Clash Verge Rev常用的圖形操作流程（底層仍是Mihomo／Meta相容核心語意），用前置規則、DNS（enhanced-mode、fake-ip、nameserver-policy）與 Sessions／Connections 對帳，幫你把「Junie CLI × Clash」變成可複製的桌面維運流程。站內若你已讀過 Cursor 多 Agent × Clash Verge Rev 或 Cursor Agent SDK 自動化篇，可把本篇當成JetBrains 終端路線的對照補篇：名詞不同，但要對齊的其實是規則排序證據鏈與 DNS 決策競爭。

為什麼 Junie CLI 特別「吃」分流與 DNS？

多數人第一次碰 Junie CLI，會先把注意力放在指令怎麼打、模型怎麼切；但一旦進入實際專案目錄開始互動，網路問題會以很不體面的方式冒出來：安裝成功但無法完成瀏覽器登入、輸入提示詞後長時間沒有回應、或啟用 BYOK 之後只有特定供應商會失敗。這些表象在工程上常常不是「模型爆掉」那麼單純，而是HTTPS 請求沒有穩定落在同一條出站策略上，或在DNS端被路由器／企業策略搶走決策，導致規則引擎看到的名字與終端機實際解析路徑不一致。

官方文件與快速入門在 2026 年已明確列出常見入口：Linux／macOS可用 curl -fsSL https://junie.jetbrains.com/install.sh | bash 取得安裝腳本，Windows則有對應的 PowerShell 一行式；驗證安裝後會期待你在專案根目錄直接執行 junie。接著你會遇到第二層網路：JetBrains 帳戶登入會把你導向瀏覽器頁面；若改走 JUNIE_API_KEY，金鑰取得頁在文件鏈結上指向 junie.jetbrains.com/cli 一類路徑；若你選 BYOK，CLI 會改成直接向第三方供應商的 API 端點送出金鑰與內容，這時候JetBrains 網域與 OpenAI／Anthropic／Google 路徑會並存。對Clash Verge Rev使用者而言，重點不是背下所有可能子網域，而是用連線紀錄把「我真的看過哪些 host」變成規則前段的硬證據。

開始前：先把三條「授權與出站」分線想清楚

在改 YAML 之前，請先用兩分鐘把場景分桶；這會直接影響你應該把哪些名字放在同一個 proxy-groups 出口上：

  1. JetBrains 帳戶登入路徑：終端機啟動後跳瀏覽器時，背景仍可能持續對 jetbrains.com 家族與 junie.jetbrains.com 內容站互動。若這一段被送去與你模型流量不同的桶位，體感會是「瀏覽器明明開了、回終端機卻一直等不到 token」。
  2. Junie API Key（用量制）：文件描述可在終端以 junie --auth="$JUNIE_API_KEY" 這類方式進入非互動流程；此時與金鑰簽發、授權校驗相關的 HTTPS 目標必須和你日常開發流量一致，否則 CI／本機腳本會出現間歇性 401 或 TLS 協商看起來「卡住」。
  3. BYOK（自備金鑰）：CLI 會依你選用的供應商改走對應 API。常見桶位包含但不限於 OpenAI、Anthropic、Google 等；請不要假設「Junie 只跟 JetBrains 說話」——那只在某些訂閱組合成立。

把這三條線畫清楚之後，你會發現：終端 Coding Agent的故障往往来自「其中一條線的子網域」被較早出現的大段 MATCH、過寬 RULE-SET 或公司網路策略提前帶走。Clash家族產品在這裡的優勢，是能把每一條規則的命中原因留在可截圖、可 diff 的文字設定裡，而不是只能看一個全黑盒子 VPN 燈號。

在 Clash Verge Rev 裡：先確定「行程有進核心」，再談規則寫多漂亮

Clash Verge Rev這類 GUI 壳最常見的落差不是你不會寫 DOMAIN-SUFFIX，而是你以为 junie 進了系統 Proxy，實際上 terminal session 根本沒跟。請依序做這幾個檢查（順序很重要）：

  • 系統 Proxy 是否寫入成功：在 macOS／Windows 各自確認系統代理開關與例外清單；若你只給瀏覽器外掛代理，終端機常仍然直連。
  • 是否需要 TUN／增強模式：某些環境下，僅靠應用層 Proxy 無法覆蓋所有子行程；此時要評估開啟 TUN 類能力時的權限成本與路由表競爭（同時開公司 VPN 時特別容易互踩）。深入概念可對照站內 Clash TUN 模式解析。
  • 使用者層級是否一致：你在圖形介面啟動的核心，與你在 Terminal／iTerm 裡跑的 junie，是否同一個登入使用者；若你在 service 帳號或 CI runner 另開帳號，請補上對該環境可用的 HTTP_PROXY／HTTPS_PROXY。

當你能用 Connections 面板看到 junie 相關連線時，才進入「要把哪些 JetBrains 域名放前面」的細節；不然越做越像替錯對象寫規則。第一次設定 Verge 介面與權限時，也可併讀macOS 上 Clash Verge 首次設定與無法連線排查，先把混合型埠與本機防火牆干擾排除。

Junie／JetBrains：用「連線紀錄驅動」的網域桶，而不是論壇最長表

下面列的是教學用起稿骨架，不是宣稱「官方永久固定清單」。2026 年的文件已清楚會接觸 junie.jetbrains.com 用以下載腳本與說明；實務上你還會在登入與帳戶流程看到 jetbrains.com 体系資源。請把下列句子讀完後就去開 Connections，對照你机器上實際出現的字串再增刪：

  • 配送與文件：junie.jetbrains.com（安裝腳本、文件站、CLI 金鑰相關入口常在這棵樹下）
  • 帳戶與授權：jetbrains.com 及可能的子域（登入／授權交錯時不要只放行文件站）
  • BYOK：第三方模型供應商：依供應商補上你在日誌裡真的看過的 API host；不要一次用超大 DOMAIN-KEYWORD 把無關站點也掃進同一桶
  • GitHub／套件週邊（若你有用插件或相依下載）：有些專案會并行拉公共 registry；這類流量不一定跟 Junie 同一出口，請避免為了「懶得切」就全部塞同一個全域策略
💡 小提示 Junie CLI同時具備互動與 headless 模式；CI 場景的網路路徑與你筆電 terminal 可能完全不同。若你在 pipeline 裡跑 junie --auth=...，請以 Runner 的 Connections 為準，而不是複製家裡電腦的 YAML。自動化 Agent 的另一條參考線是Cursor Agent SDK×Clash那篇的「雲端執行 vs 本機 cwd」分段。

複製區：把 JetBrains／Junie 與 BYOK 供應商放回 prepend 段

下面是一段示意 YAML：請把 YOUR-JUNIE-GROUP、YOUR-BYOK-GROUP 換成你 Profiles 裡真的存在的策略組名稱；若你暫時不需要拆分，也可以先並到同一組，但拆桶的好處是出問題時更容易看出「是 JetBrains 端卡住還是模型供應商端卡住」。請確認這些條目會在訂閱檔末端大段 MATCH 或過寬 RULE-SET 之前生效（實務上多用 prepend-rules 或 shell 的 mixin／merge）：

# prepend sketch — replace group names with your proxy-groups
prepend-rules:
  - DOMAIN-SUFFIX,junie.jetbrains.com,YOUR-JUNIE-GROUP
  - DOMAIN-SUFFIX,jetbrains.com,YOUR-JUNIE-GROUP
  # BYOK buckets (keep only providers you actually enabled)
  - DOMAIN-SUFFIX,openai.com,YOUR-BYOK-GROUP
  - DOMAIN-SUFFIX,anthropic.com,YOUR-BYOK-GROUP
  - DOMAIN-SUFFIX,googleapis.com,YOUR-BYOK-GROUP
  # Extend only from live Connections logs; avoid blind bulk KEYWORD.

這段的關鍵不是「貼了就會好」，而是建立一套可瀏覽器外驗證的習慣：每當 Junie 升級、文件換 CDN、或你切換 BYOK 供應商，就回頭檢視 prepend 是否仍與日誌一致。Clash Verge Rev使用者也可以把這類片段放在本機固定 merge 檔，避免訂閱一打更新就把你手動前移的教學條目洗到視線外。

DNS：別讓 fake-ip 變成「你看得到規則、連線卻邏輯分裂」的根因

很多人在 Clash 教學裡第一次學到 fake-ip 會以為它只是性能優化；但在 終端 Coding Agent這種短時間大量 HTTPS、又可能夹杂长連線的場景裡，fake-ip 與 enhanced-mode、nameserver-policy 的组合会直接决定規則引擎到底「看得到什麼名字」。當路由器對 53 埠做強制轉發、或公司 DNS 對特定類別域名返回與公共 Resolver 不一致的答案時，最常見的體感是：瀏覽器登入偶爾成功、終端機里同一時段的 API 呼叫却長逾時。

實務排查請守三個原則：一次只改一個變因；永遠保留一份對照組 Profile；每次變更都用同一個 Junie 操作時間軸重播。如果你在 BYOK 模式下懷疑「只有某家供應商特別容易卡住」，可以先對照那家供應商的 API 域名在 Connections 是否被錯送到 DIRECT，再回頭看 DNS 是否把解析決策拉進另一套策略。需要 Anthropic 在終端機線索的對照範本，可交叉閱讀Claude Code CLI 逾時與 Clash 規則篇；那是不同產品，但「TLS 正常、工具卻逾時」的分段心法相近。

症狀分桶：用 Sessions／Connections 對上你的故事

当你不把問題口述成「Junie 壞掉」而改成「哪個 host 在哪种策略桶」，排查速度會差一個量級：

  • Type I：卡在安裝或首次啟動：優先檢 junie.jetbrains.com 是否被送往能穩定完成 TLS 的出口；這一段若走錯，後面不必談模型品質。
  • Type II：瀏覽器登入成功但終端機沒有回應：常見是授權回跳相關子域仍在直連或被 GEO 集束帶走；請把日誌裡新出現的名字補到前段。
  • Type III：只有 BYOK 的某一個供應商失敗：十之八九是該供應商 API 域名沒進你的前置桶，或金鑰環境變數在子 shell 沒繼承；先用 Connections 判斷是哪一類。
  • Type IV：同一 Wi-Fi 只有你的筆電有問題：把懷疑方向拉回本機多代理／DNS Client 叠床架屋；若所有裝置都坏，較像上游線路或企業邊界。

要把這套方法學成長期可維護的流程，可以搭配本站 Clash 基礎教學把規則模式、訂閱更新與日誌閱讀順序補齊；之後你在任何一個JetBrains或第三方 Agent 产品上碰到類似形狀，都能沿用同一套證據鏈。

常見問題（頁面內對照）

安裝腳本 curl 得到內容但 junie 還是連不上，先懷疑什麼？

先拆兩段：下載／校驗與後續授權。請看 Connections 裡實際連線的主機名與策略桶，不要只用「瀏覽器能不能上網」當唯一判準。

BYOK 後換模型就全壞，比較像規則還是 DNS？

兩者都要查：換模型等於換 API 端點集合；同時不同 CDN 在企業 DNS 下可能出現不一致解析。請用單因子實驗與對照組 Profile 分開驗證。

我可以直接貼論壇最長規則嗎？

不建議。過寬的 KEYWORD 與訂閱更新會帶來誤傷與排序漂移；請只前移你在日誌中看過的名字，並保留可審計的 YAML。

相較於把希望寄託在「一鍵全域加速」、卻無法告訴你哪個 API 主機被送去哪個出口的方案，Clash生態（無論透過 Clash Verge Rev 或其他 Meta／Mihomo 相容客戶端）的核心價值在於：API 分流、DNS 與訂閱層級可以被寫成可 review 的文字，並用連線紀錄把「逾時」對回具體 host 與命中列。對正在試 Junie CLI 這類終端 Coding Agent的開發者而言，這種可對帳性通常比單純拼節點延遲更重要——因為 Agent 的每一步工具呼叫都仰賴連續、可預測的 HTTPS 路徑。若你希望把同樣方法延伸到其他桌面專案，又需要一個可長期更新的安裝入口，建議從本站 Clash 下載頁挑選與環境相符的客戶端與核心組合，再把本文的 prepend、DNS 與對帳步驟壓進你的個人 runbook：→ 前往下載頁取得 Clash 相關元件並驗證你的 Verge Rev 設定是否能覆蓋終端機行程。