「遅い」の正体を一言で言い切らない
プロキシ越しのブラウジングで困るのは、往々にして往復遅延（RTT）だけでは説明できないタイプの不快感です。初回の TLS ハンドシェイクが長い、DNS の失敗がタイムアウトまで待たされる、HTTP/3 が UDP 経路でだけ詰まる、ルール評価や巨大なルールセット I/O が CPU を食う、といった要因が重なり、結果として「Clash を入れたら全体が重くなった」ように感じることがあります。
改善の出発点は、どのレイヤで時間が消えているかを仮説立てすることです。本章では、現場で再現性を上げやすい順番に沿って十のレバーを並べます。数字ほど厳密なベンチマークではなく、設定と運用の両面から「試す価値が高い順」に並べている点をご理解ください。
実践テクニック10選
1. 遅延計測つきの url-test／fallback を整える
手動の select だけで運用すると、ノードの一時劣化のたびに切り替え作業が増え、体感のばらつきが大きくなります。url-test で定期的に計測し、しきい値と間隔を過激に短くしすぎないバランスを取ると、勝手に悪い出口から逃げられて安定しやすくなります。計測先 URL は、利用シーンに近いエンドポイントを選ぶほど実測と相関しやすいですが、過度なポーリングは逆効きにもなるため、クライアントのプリセット値から少しずつ寄せていくのが無難です。
fallback は「到達性優先」の逃げ道として有効です。動画や大容量転送と、チャットや SSH のような小さな往復が効く通信では最適な出口が一致しないことがあるため、用途別にプロキシグループを分けると調整が楽になります。
2. ノードの地理・帯域・混雑を見て「候補を絞る」
サブスクリプションに数十個ノードが並んでいても、日曜夜間の混雑や遠回りのピアリングで帳簿上は近いのに遅いことは珍しくありません。GUI でレイテンシ表示が出るクライアントなら、上位数個だけを手元で往復試験し、体感が良いものに固定するのも一案です。
「安価な共有ノード」ほど、特定時間帯だけ品質が落ちるパターンが出やすいです。速度より安定性を優先したい読者は、同じ価格帯でも混雑しにくい地域・事業者を試し、ダメなら切り替える運用に寄せるとストレスが減ります。
3. DNS のモードと解決順を見直す
Fake-IP と redir-host のどちらを使うか、nameserver と fallback の関係、ブラウザ内蔵の DNS-over-HTTPS との競合——ここがずれると、ルールは正しくても名前解決の段階で待たされることがあります。症状が「特定ドメインだけ初回が遅い」に偏るときは DNS を疑う価値が高いです。
切り分けの基本は、問題のホスト名をクライアントのログで確認し、OS の解決結果と突き合わせることです。社内ポリシーで DoH を必須にしている場合は、Clash 側の DNS 設定と役割分担を文章化しておくと、再発時の復旧が速くなります。
4. ルール順で「広いマッチ」を上に置きすぎない
ルールは上から評価され、最初の一致で打ち切られます。GEOIP や巨大な RULE-SET を先頭付近に置くと、細かい例外が永遠に評価されない位置に追いやられます。結果として意図しない出口に流れ、遠回りや追加検証ページのループに見える遅さが出ます。
分流の基本は、当ブログの分流ルール入門で整理したとおり、狭い例外を上、広い塊を下、最後に MATCH です。購読テンプレを更新した直後にだけ遅くなる場合は、テンプレ側の順序変更が紛れ込んでいないかも確認してください。
5. ルールセットの肥大化と更新間隔を抑える
数万行規模のルールを毎分更新する構成は、ディスク I/O と再コンパイル負荷で微妙なカクつきを生むことがあります。Rule Providers の更新間隔を現実的な値にし、ローカル例外は小さなファイルに分離するほうが長期運用に有利です。設計の考え方はRule Providers 解説とつながります。
「ルールを増やせば安全」ではなく、評価にかかるコストと可読性のトレードオフだと捉えると、速度面の最適化もしやすくなります。
6. システムプロキシと TUN の使い分け
システムプロキシだけでは取りこぼすアプリがあり、逆に TUN は権限や競合の影響を受けやすいです。体感が「ブラウザだけ遅い」「ターミナルのみ直結」のように分岐するなら、モードの差を疑ってください。全体をルールの下に載せたい読者は、TUN モードガイドで前提と検証手順を押さえると安全です。
切り替えのたびに再起動が必要なクライアントもあるため、変更は一つずつ入れ、ログで副作用を確認する癖をつけるとよいでしょう。
7. UDP／HTTP3（QUIC）の経路を確認する
HTTP/3 は QUIC（UDP）を使うため、TCP だけを想定した例外や、UDP を落とす中間機器と組み合わさると、「ページは開くのに埋め込みだけ遅い」といった部分遅延に見えます。ブラウザ側で一時的に HTTP/3 をオフにして症状が変わるか比較すると切り分けが速いです。
ゲームやビデオ会議などリアルタイム系でも UDP の扱いは重要です。クライアントの説明と Mihomo 側の仕様を突き合わせるときは、Mihomo の GitHubを参照してください。インストールパッケージの入手は混線を避けるため、当サイトのダウンロードページを主導線にし、GitHub はソースと Issue 確認に使い分けると読者にも親切です。
8. 多重接続と帯域の食い合いを避ける
同一ノードに対してブラウザの多数タブ、同期ソフト、バックアップ、コンテナレジストリが同時に張り付くと、単一 TCP のウィンドウや公平性アルゴリズムの影響で体感だけ遅くなることがあります。ルールで大容量先を別出口に逃がす、時間帯をずらす、QoS をルーター側で入れる、など上流の対策も視野に入れます。
Clash 側では、用途別グループに分けておくだけでもログ上の見通しが良くなり、ボトルネックの当たりが付きやすくなります。
9. クライアントとコア（Mihomo）を適切に更新する
古いビルドのまま新しいプロトコルや OS の変更に追従すると、暗黙の不具合やパフォーマンス退化が積み上がります。逆に、検証なしの即時追従もリスクがあるため、リリースノートを読み、問題が出たら一つ前に戻せるようにしておくのが現場流儀です。
GUI の「アプリ更新」と「コア更新」が分かれている製品では、どちらを上げたかをメモしておくと、トラブル時の切り分けが早くなります。
10. ローカル回線・Wi-Fi・IPv6 を疑う
プロキシ以前に、Wi-Fi の電波環境、省電力モード、VPN の二重掛け、IPv6 の優先と中間機器の不整合などがボトルネックになることは珍しくありません。Ethernet で試した瞬間に改善するなら、出口ノードより先を疑うべきサインです。
IPv6 だけ特定サイトで詰まる場合、一時的に IPv6 をオフにして再現性を見る、あるいはルーターのファームウェア更新を検討する、といった古典的な手も有効です。
現場向けの短いワークフロー
まずブラウザだけ／全アプリで再現するかを分け、次に DNS とルールの最初のマッチをログで確認し、そのうえでノードと url-test を触る——この三手順を守ると、設定迷子になりにくいです。用語のつながりを俯瞰したい場合はドキュメントとチュートリアル一覧も併読すると、システムプロキシや TUN、DNS の章との対応が掴みやすくなります。
同種ツールのなかでも、Clash エコシステムはルール表現と可視化の蓄積が厚く、試行錯誤のコストを下げやすいのが強みです。いきなり完璧な数値を追わず、上から順に一つずつ仮説を潰していくのが、長く快適な運用への近道です。