CursorやGitHubの応答が遅い？Clash分流でAIコーディングとnpm取得を整える（2026）

遅さが出る場所を切り分ける

まず症状を混同しないことが重要です。エディタの補完やチャットが遅いのは、HTTPS の往復遅延やDNSの失敗が原因のことが多く、npm install が帯域ではなくTCP接続で詰まるのは、レジストリの向き先や企業プロキシの検査が絡むことがあります。GitHub の clone／fetch が遅い場合も、同一ホストとは限らず、オブジェクトストレージや CDN の別ドメインに振られるケースがあります。Clash は「どのドメインをどのポリシーに送るか」を一貫して決められるので、ルールの上に載るDNS解決とセットで設計する必要があります。DNS だけ別経路になると、ルールは正しくても実体のIPが期待とズレることがあります。詳細は Meta コア DNS リーク防止ガイド を参照してください。

システムプロキシと TUN：ターミナルと GUI をどう覆うか

Windows や macOS の Clash 系クライアントでは、大きくシステムプロキシとTUN（仮想ネットワーク）の二系統があります。ブラウザや多くの GUI アプリはシステムプロキシを尊重しますが、一部の CLI は環境変数 HTTP(S)_PROXY を見るだけ、あるいはプロキシを無視して直結する実装があります。TUN を有効にすると、OS のルーティング層でトラフィックを捕捉しやすくなり、ターミナルからの git や npm まで含めて「抜け漏れ」を減らせます。一方で、社内VPNや別のフィルタと二重にトンネルになると逆に遅くなるので、まずはシステムプロキシだけで十分か、TUN が必要かを切り分けます。手順の全体像は Clash Verge Rev の TUN モードガイド にまとめています。初回セットアップは Windows での Clash Verge Rev 導入（2026） と併せると流れが掴みやすいです。

GitHub まわりの分流：ドメイン単位の最小例

購読ルールに「GitHub 系」が含まれていればそのまま使えますが、自分で足す場合はドメインsuffixでまとめるのが扱いやすいです。公式ホストに加え、リリース資産や raw コンテンツが別サブドメインになることがあります。コミュニティのルールセットを併用する場合は、ACL4SSR と Loyalsoldier の比較記事 で、保守と網羅性のトレードオフを把握してから選ぶと運用が楽です。以下は説明用のスケッチです。実際のポリシー名（PROXY や 节点选择 など）は利用中のプロファイルに合わせて置き換えてください。

# Example: send GitHub-related domains to your proxy policy
# Replace YOUR_PROXY_GROUP with the name in your profile

rules:
  - DOMAIN-SUFFIX,github.com,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,githubusercontent.com,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,github.io,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,githubassets.com,YOUR_PROXY_GROUP

GEOIP ルールだけに頼ると、CDN のエッジ位置によっては意図と異なる経路になることがあります。特定サービスで詰まるときは、ログで実際にヒットしたドメインを拾い、上のように DOMAIN-SUFFIX や DOMAIN-KEYWORD で足すのが確実です。

npm：registry を変えるか、プロキシで抜けるか

npm の遅さは二種類あります。一つはレジストリの地理的位置とTLS往復、もう一つはパッケージ tarball のサイズと帯域です。社内でミラー（registry.npmjs.org 以外）を必須にされている場合、Clash でどこまで代理するかはそのミラーのドメインに依存します。公的またはチーム提供のミラーに切り替えるとレイテンシは下がる一方、セキュリティポリシーと整合するかは別問題です。ミラーを使わずに本家へ行く場合は、npm config get registry で実際の URL を確認し、Clash のルールでそのホスト名が意図したポリシーに流れるようにします。pnpm や yarn も、結局は HTTPS のドメイン単位で見れば同じ考え方です。

# Example: match your configured registry host (adjust suffix)
rules:
  - DOMAIN-SUFFIX,npmjs.org,YOUR_PROXY_GROUP
  - DOMAIN-SUFFIX,npm.pkg.github.com,YOUR_PROXY_GROUP

GitHub Packages を registry にしている場合は、npm.pkg.github.com など認証付きホストが追加で現れます。ルールに無いと DIRECT に落ちて遅延やタイムアウトの原因になるので、失敗時はクライアントログの接続先ホスト名を必ず確認してください。

Cursor など AI エディタ向け：ドメインは「固定一覧」よりログ優先

Cursor のような製品は、バージョンアップでAPI エンドポイントや CDNが増減します。そのためブログ記事に「このドメインだけで一生」と書き切るのは現実的ではありません。運用上は、接続ログとドメインのヒット一覧を見ながら、遅い／失敗するホストをルールに追加するループが安定します。おおまかには cursor を含むホスト名や、製品ドキュメントに記載の API ドメインをプロキシ側のポリシーへ寄せる、という方針になります。社内で許可リスト型のファイアウォールがある場合は、Clash 以前に許可ドメインの更新がボトルネックになる点に注意してください。

# Example sketch: broaden with DOMAIN-KEYWORD carefully (may over-match)
rules:
  - DOMAIN-KEYWORD,cursor,YOUR_PROXY_GROUP

DOMAIN-KEYWORD は便利ですが過剰マッチしやすいので、安定運用では DOMAIN-SUFFIX に分解していくのがおすすめです。複数の開発者で共有するなら、チーム内で「追加したドメインと理由」を短くメモしておくと、数か月後の自分が助かります。

DNS をルールと矛盾させない

分流は「IP アドレスに変換されたあと」に効くため、DNS がクライアント外で勝手に解決されていると、ルールが想定したGEOやポリシーとズレます。Clash Meta 系では fake-ip や nameserver-policy などで細かく制御できますが、設定が増えるほどループや漏れのリスクも上がります。GitHub や npm のトラブルで「ブラウザだけ通る」現象が出たら、まず DNS を疑う価値があります。すでに DNS ガイド で触れたとおり、TUN と DNS ハイジャックの組み合わせは強力ですが、設定ミス時のデバッグ難度も上がります。

おすすめの作業順（最小）

1. クライアントで Rule モードを前提に、購読ルールが読み込めていることを確認する。
2. システムプロキシだけでブラウザとエディタを試し、足りなければ TUN を検討する（TUN ガイド）。
3. 遅い操作を一つに絞り、接続ログのドメインを取る。
4. DOMAIN-SUFFIX などでルールを追加し、DNS が Clash 側と矛盾していないか確認する。
5. npm だけ別レジストリにした方が早い場合は、チームのセキュリティ方針と両立するか判断する。

まとめ

Cursor・GitHub・npm の快適さは、単一のチェックボックスではなく、Clash の分流・システムプロキシ／TUN・DNS の三つ巴で決まります。ホットな話題に乗せて設定を増やしすぎるより、ログで事実を取り、ドメイン単位で足していく方が2026年現在もっとも再現性が高いです。クライアント本体の入手と更新は、リリースノートの確認とあわせて 公式ダウンロードページ から行うと、インストーラとソース閲覧の目的が混ざりにくくなります。

→ Clash を無料ダウンロードし、開発環境のルーティングを落ち着かせる