Central／エージェントが「ログインだけ」「API だけ」壊れやすい理由

JetBrains 側はアカウント基盤と IDE を束ねる流れが強まっており、ブラウザでの JetBrains Central サインインから IDE へのトークン受け渡し、続く プラグイン更新、リモート開発・クラウド連携・AI エージェント系機能までが、短時間に複数ホストへ散らばりやすい構造です。Clash や企業プロキシ下では、ブラウザは正常でも IDE プロセスだけタイムアウト、その逆、といった報告が出やすく、原因は単一サービスの障害より、ルーティングと DNS の食い違いであることが多いです。

典型的には OAuth／同意画面（アカウント系）、マーケットや CDN 上の静的ファイル（JS／アイコン／計測）、バックエンド API（ライセンス確認・同期・エージェント呼び出し）が連鎖します。ここで account.jetbrains.com だけプロキシに乗り、配信用サブドメインが DIRECT のまま不安定な経路へ落ちる、短縮ドメインが広告枠に誤爆する——出口が行ごとに割れると、UI は「読み込み中」のまま進まず、ログには断続的な i/o timeout が並びます。まず押さえたいのは「すべて同じ国へ飛ばせばよい」ではなく、観測されたホスト集合を同一ポリシーへ揃えることです。

IDE 周辺のログイン滞留は他製品でも似た型があり、ホスト集合の捉え方の参考には Cursor と Clash のログイン・AI タイムアウト や、CLI と CDN が割れやすい OpenCode CLI のドメイン分流 が近いです。ただし JetBrains は jetbrains.com 名前空間と配信スタックが中心で、プロファイルを混ぜず JetBrains 用の束ねを独立させておくと後からの追記が楽です。

ℹ 観測のコツ：Central ログイン操作やプラグイン更新、エージェント起動のタイミングで Clash のライブ接続を開き、jetbrains.com 配下に加えて plugins.jetbrains.com、download.jetbrains.com、resources.jetbrains.com、計測や短縮で現れるホストが混ざっていないかを見ます。同じ用途の行が別ポリシーに分かれていれば一括で直せることが多いです。

JetBrains 系ホストの三つの束ね方（認可・配信・CDN）

説明を単純化するため、大枠を三つに分けます。① 認可とアカウント：サインインや組織 SSO のリダイレクト、ライセンスポータル、Central 周辺の同意画面など。② IDE 機能のバックエンド API：同期、マーケット問い合わせ、クラウド連携、エージェント呼び出しに見える REST／WebSocket 系。製品版や地域によりホスト名は増減し、ログで拾うのが最も安全です。③ 静的配信と周辺 CDN：アイコンやアセット、場合によってはサードパーティ CDN や短縮リンク経由のリダイレクト。ここが別出口に落ちると、OAuth 自体は成功して見えても 後続の初期化だけ失敗するパターンが出ます。

分流設計の第一歩は DOMAIN-SUFFIX,jetbrains.com を同一ポリシーグループ（例：JETBRAINS_SUITE）へ揃えることです。職場で jetbrains.com の広い行が許されない場合は、ログに出た FQDN を DOMAIN で足し足しにします。短縮ドメインや計測系は環境差が大きいので、ブロックリストや巨大カテゴリ行が先に当たっていないかも同時に確認します。ルールの並べ方全般は ルール分流のベストプラクティス に整理してあります。

増え続けるホストは ルールセットでベースを取り、JetBrains 固有の欠けだけを手元の短いリストで補う rhythm が メンテしやすいです。GUI で接続ログが読みやすいクライアントを先に決めるのも有効で、選び方は Clash クライアントの選び方 を参照してください。

最小ルール例とルールセット運用

下の YAML は出発点のイメージです。実環境の proxy-groups 名に合わせ、ログに出た FQDN へ追記してください。DOMAIN-SUFFIX,jetbrains.com はマーケットやダウンロードまで広く巻き込みます。国内トラフィックは従来どおり GEOIP や国内リストで DIRECT に逃がし、JetBrains 関連だけを束ねるのが典型です。

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,jetbrains.com,JETBRAINS_SUITE
  - DOMAIN-SUFFIX,jetbrains.space,JETBRAINS_SUITE
  - DOMAIN-SUFFIX,kotlinlang.org,JETBRAINS_SUITE
  - DOMAIN,data.services.jetbrains.com,JETBRAINS_SUITE
  - GEOIP,JP,DIRECT
  - MATCH,DIRECT

jetbrains.space や kotlinlang.org を入れるかは組織の利用範囲次第です。不要なら外してください。ルールプロバイダを複数重ねると、更新順で意図しない行が上に来る事故が起きます。購読とノード保守 で、ルールセット URL がプロキシループに落ちていないかも併せて確認してください。

IDE と TUN：システムプロキシを読まない経路への落とし込み

IntelliJ 系は システムプロキシ を尊重する一方、JVM オプションや独自実装でプロキシ設定を無視するケースもあります。Clash が「システムプロキシモード」でも、IDE が読まないとルールは効きません。そこで TUN で OS のルーティングテーブルに載せ、プロセスを問わず同じルール評価へ落とす方法が再現性が高いことが多いです。macOS で拡張や別 VPN と衝突する典型は macOS の TUN とシステム拡張・プロキシ衝突 にまとめてあります。Windows なら Clash Verge Rev の Windows11 TUN も参考になります。

TUN を有効にしたあと「全体がおかしい」場合は、MATCH や国内リストの順序から疑うのが早いです。挙動の整理は TUN モード詳解 を参照してください。

DoH／fake-ip とドメインルールの整合

OS 側の DoH と Clash の fake-ip、社内 DNS の書き換えを重ねると、「名前は返ったのに証明書が合わない」「命中ポリシーが期待と違う」といった症状が出ます。JetBrains 系もサブドメインが多く、nameserver-policy とフォールバック順の設計がログイン成功率に直結します。具体例は Clash Meta の DNS（nameserver／fallback／fake-ip） にまとめてあります。ルールを足したのに改善しないときは、ルール以前に どのリゾルバが答えているかを疑ってください。

企業ネットワークでは社内 DNS が公開ドメインを書き換えることがあり、その場合は Clash だけ直しても再現しません。IT へ渡すメモには、失敗ホスト名・得られた A／AAAA・Clash のポリシー命中行を添えます。

ログと検証：OAuth と API タイムアウトの見分け

Clash／Mihomo 系のログでまず見るのは TCP 接続の成否、Router でのルール命中、DNS の応答です。i/o timeout が続くなら経路かノード、certificate や tls 行が混ざるなら名前と証明書の不一致を疑います。段階の読み分けは 接続ログの timeout と TLS がそのまま使えます。Central 操作中に jetbrains.com 配下だけ別ポリシーへ流れている、静的ドメインが REJECT に当たっている——そうした一行の差がスピナーや総タイムアウト表示の正体であることが多いです。

ルールは上から評価されるため、広い GEOIP や広告カテゴリ行が JetBrains 向けの具体行より上にあると、意図した分流が潰れます。更新直後に壊れたら、ルールプロバイダの版を一つ戻して差分を見るのが安全です。

Microsoft/GitHub 系の IDE 周辺ルーティングは GitHub Copilot と Microsoft ドメイン分流、Google 側の AI クライアントは Gemini Mac の API／CDN 分流 が近い型です。いずれも「認証・API・CDN の三層」を揃える話ですが、ホスト集合が異なるため、プロファイルを分けておくと衝突が減ります。

⚠ コンプライアンス：法令・組織ポリシー・JetBrains 各種利用規約を遵守してください。本稿は許可されたネットワークでの経路衛生の話であり、不正アクセスや正当なセキュリティ回避を示すものではありません。

よくある質問

ブラウザの Central ログインは成功するのに IDE だけダメです。最初に何を見ますか？

IDE プロセスがシステムプロキシを読んでいるか、TUN でルーティングが揃ったかを確認します。続けてライブ接続で、ブラウザ成功時と同じホストが IDE からも同一ポリシーへ流れているかを比較してください。

DOMAIN-SUFFIX,jetbrains.com だけで足りますか？

多くの環境では出発点として有効ですが、短縮ドメイン・外部 CDN・組織 SSO の別名前空間が混ざることがあります。ログで拾い漏れがないかを最終判断にしてください。

エージェント機能だけタイムアウトします。ノードが悪いのでしょうか？

先にルーティングと DNS を揃えてください。改善しない場合のみ、別ノードやベンダー側の一時障害を疑います。総タイムアウト表示はしばしば 先頭の数ホストの失敗が原因です。

チェックリスト

  1. 利用地域・契約・職場方針で JetBrains サービスと Clash の併用が許可されているか確認する。
  2. Central ログイン、プラグイン更新、エージェント起動の各タイミングでホスト一覧を取り、同一用途が同一ポリシーか確認する。
  3. TUN とシステムプロキシの組み合わせを切り替え、ライブ接続でポリシーが変わるか比較する。
  4. DNS（DoH／fake-ip／社内リゾルバ）とルールの整合を Meta DNS の記事 の観点で点検する。
  5. 広い捕捉行が JetBrains 向けの具体行より上に来ていないか確認する。
  6. 購読とルールセット更新がループせず成功しているか確認する。
  7. ルールを直したあとも失敗する場合のみ、ノード品質とベンダー側障害を切り分ける。

メモを残しておくと、次に IDE がアップデートでホストを増やしたときの差分追跡が楽になります。

まとめ

JetBrains Central と IDE 内エージェントは、単一ドメインのチャット UI ではありません。OAuth・API・静的 CDNが短い連鎖で動き、Clash のドメイン分流で片道だけ別出口に落ちると、ログインやクラウド機能が終わらないように見えます。答えは「全部同じリージョンへ」より、実測ホストを同一ポリシーへ束ね、DNS と TUN／システムプロキシの前提を一致させることにあります。

ルールセットでベースを取り、欠けたホストだけを手元で足す——このリズムは 2026 年のエージェント実装が増える IDE 全般に通じます。ログの読み方は timeout／TLS 記事、DNS は Meta DNS 記事、macOS の衝突は TUN 記事へ分散させてあるので、症状に近い章から読み返すと迷子になりにくいです。

「とりあえず一括トンネル」より、Clash の明示ルールは初手は手間でも、観測可能な切り分けに落ちます。一方で、GUI の薄いクライアントや、ルール更新が属人化している運用では、ホストが増えた瞬間に再び割れが再発しやすく、ログの取り方まで含めて再現性のあるワークフローが必要になります。

Clash V.CORE は、接続ビューとログを素早く行き来でき、ルールセットの版戻しや TUN とシステムプロキシの切替も扱いやすい前提で設計されています。不透明な一括プロファイルより、JetBrains 用の束ねを独立させて育てられる方が、Central とエージェントの将来更新にも耐えます。

→ 無料で Clash V.CORE をダウンロードし、スピナーを眺める時間ではなく、実際のコーディングに戻れるようにしてください。