Clashのノードがタイムアウトして繋がらない時の対処法:サブスクリプション・ポート・プロトコル設定を順に確認
全ノードがタイムアウトする場合と一部のノードだけがタイムアウトする場合では原因が異なります。サブスクリプションの有効性、ローカルの速度測定方法、ポートとプロトコルのパラメータ、システム時刻とファイアウォールの順に確認し、各ステップの判断基準と対処法を解説します。
詳細図を見る →図番 RUMEN-01 ・ 着工図 ・ スケール 1:1
本サイトは施工図面のようにClashの設定手順を体系化しています。まず5大プラットフォームのインストールパッケージを入手し、図解に沿ってサブスクリプション導入とシステムプロキシ設定を完了、最後にルール分岐の章で日本国内は直接接続、海外サイトはプロキシ経由と一括設定します。各手順には索引と根拠があり、いつでも見返せます。
5つのプラットフォームはそれぞれ独立したクライアント系譜を持ちます。プラットフォームの入口をクリックすると、ダウンロードページの該当セクションに直接移動します。各プラットフォームではメンテナンス活発度順に選択可能なクライアントを掲載し、システム要件表も併記しています。
左側は詳細図の目次、右側は対応するセクションです。各セクションではその機能が解決する課題、有効化の方法、類似方式との違いを説明し、必要な設定例も掲載しています。
ルール分岐は、Clashと「全体プロキシ」型ツールとの根本的な違いです。接続が確立されるたびに、エンジンはルールテーブルを上から順に照合し、DOMAIN-SUFFIX、GEOIP、RULE-SET などのルールタイプによって、その接続を直接接続・プロキシ経由・拒否のいずれにするか決定します。日本国内のサイトは直接接続でネイティブな速度とログイン環境を保ち、海外サイトは必要に応じてプロキシ経由、広告ドメインは即時ブロック——3方向の出口を一度設定するだけで長期にわたり有効です。手動でスイッチを切り替える手間はもう不要です。ルールテーブルは読みやすく編集も容易で、照合順序はそのまま記述順、末尾の MATCH がフォールバックとして働くため、動作は完全に予測可能です。
rules:
- DOMAIN-SUFFIX,openai.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY
サービス提供者が発行するサブスクリプションURLは、実質的にはリモートで管理された完全な設定情報です。ノード一覧、ポリシーグループ、ルールテーブルが1つのURLにまとめられています。クライアントの「設定 / Profiles」ページにこのURLを貼るだけで一括読込が完了し、サーバーアドレスやポートを一つずつ入力する必要はありません。サブスクリプションは定期自動更新に対応しており、サービス提供者側でノードを変更するとローカルにも自動で反映されます。複数のサブスクリプションを併存させ、ワンクリックで切り替えることも可能で、互いに干渉しません。ノードのパラメータを手作業で管理する従来方式に比べ、サブスクリプション機能は最もミスが起きやすい工程をまるごと日常操作から取り除きます。導入手順は入門チュートリアルの第2節に図解番号付きで示しています。
システムプロキシモードは、OSにHTTP/SOCKSプロキシアドレス(デフォルトは127.0.0.1:7890)を登録する方式です。ブラウザやシステム設定に従う大半のアプリは自動的にClash経由になり、軽量で負荷が小さいため日常利用の第一選択となります。ただしコマンドラインツールやゲームクライアント、システム設定を読まないソフトなど、一部のプログラムはこの登録を回避してしまいます。TUNモードはこの問題に対応するもので、システム内に仮想ネットワークアダプタを作成し、ネットワーク層から全トラフィックを引き受けるため、いかなるプロセスも回避できません。Windowsでは有効化にサービスモードでのドライバインストールが必要、macOSでは「拡張モード」と呼ばれ、Androidの VpnService トンネルは実質的に同等の仕組みです。両モードの使い分けと設定手順はチュートリアルおよび設定大全の対応章を参照してください。
ノード数が増えると1つずつ試すのは現実的ではありません。ポリシーグループは用途別にノードをグループ化します。select グループは手動指定、url-test グループは定期的に測定用URLへ実際のリクエストを送り、遅延が最も低いノードを自動選択、fallback グループは優先ノードが使えなくなった際に順番に自動切り替えます。ルールテーブルが参照するのはノード名ではなくグループ名なので、ノードの入れ替えがあってもルール構成には影響しません。クライアント画面上でグループ全体をワンクリック遅延測定でき、実測値に基づいて選択理由が一目で分かります。この仕組みによって「数十個のノードをどう管理するか」という日常の負担が、一度きりの構造設計で済むようになります。
proxy-groups:
- name: PROXY
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
Clashは特定の1つの閉じたソフトウェアではなく、コアと設定形式のオープンな標準です。コアはmihomoプロジェクトが継続的にメンテナンスし、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android などのGUIクライアントがその上でそれぞれ進化しています。すべてのクライアントが同一のYAML設定を読み、同一のサブスクリプション形式に対応しているため、クライアントを乗り換えても学び直しは不要で、サブスクリプションもそのまま使えます。あるクライアント(Clash for Windowsなど)がメンテナンス終了しても、活発なプロジェクトへの移行は画面が変わるだけです。コードは公開されておりいつでも検証可能、更新のペースはコミュニティ主導——これが本サイトが長期的な選択肢として推奨できる理由です。各クライアントの比較はクライアント比較ページを参照してください。
完全な設定手順は入門チュートリアルページに収録しています。ここではメインの3ステップのみを示し、各ステップはチュートリアル内の該当セクションに対応します。
ダウンロードページでお使いの環境に対応するクライアントを選択し、インストールします。WindowsとmacOSはウィザードに従うだけ、Androidは初回起動時にVpnServiceの許可が必要です。
サービス提供者から発行されたサブスクリプションURLをコピーし、クライアントの「設定」ページに貼り付けて導入します。ノード一覧が読み込まれたら、ポリシーグループで出口ノードを選択します。
システムプロキシのスイッチをオンにし、ルールモードを選択、海外サイトにアクセスして接続を確認します。つながらない場合はチュートリアル末尾の対応表を順に確認してください。
長期利用するネットワークツールを選ぶうえで、プロジェクトのメンテナンス状況は見た目よりも重要です。以下の4点は公開リポジトリで一つずつ確認できます。
Clashのオリジナルコアは2018年からオープンソースとして公開され、YAML設定、ポリシーグループ、ルール分岐という基本形態を確立しました。元のリポジトリがアーカイブされた後、コミュニティのフォークであるClash.Metaが開発を継承し、mihomoに改名。より多くのプロトコル対応とルールタイプを補強し、現在は事実上の標準コアとなっています。本サイトのチュートリアルと設定大全はいずれもmihomoコアの挙動に基づいています。
コアはプロトコル実装とルール照合を担い、GUIクライアントは画面表示・サブスクリプション管理・システム統合を担うという形で、それぞれ独立して進化しています。Clash Verge Rev や FlClash などのクライアントはmihomoコアを内蔵し、そのバージョン更新に追随するため、利用者がコアファイルを個別に管理する必要はありません。サーバーやルーターの用途ではコアのバイナリを直接実行し、同じ設定ファイルを使います。
各アクティブなクライアントはオープンソースプラットフォーム上で正式版をリリースし、更新ログも一つずつ公開されています。本サイトのダウンロードページにあるリンクは各プロジェクトの現行リリースを指しており、バージョン情報はリリースに応じて自動的に同期・更新されます。メンテナンス終了済みのクライアント(Clash for Windows、ClashX Meta)はアーカイブとして残しつつその旨を明示しており、新規導入としては推奨していません。
コアと主要クライアントの完全なソースコードは公開リポジトリで管理されており、プロトコル実装、DNS処理、ルール照合ロジックを1行ずつ確認でき、自身でクローンしてビルドすることも可能です。コアの実装を検証したい方は、以下のコマンドでmihomoコアのソースコードリポジトリを取得できます。
git clone https://github.com/MetaCubeX/mihomo.git
着工前に最も多く聞かれる4件を掲載。全質問はFAQページにカテゴリ別に収録しています。
次の3点を順に確認してください:クライアントのシステムプロキシのスイッチがオンになっているか、現在のポリシーグループで有効なノードが選択されているか(ノードに対して遅延テストを実行し、タイムアウトなら利用不可)、ブラウザにプロキシ系拡張機能が入っていてClashと衝突していないか。3点すべて問題なくても繋がらない場合は、FAQページの「トラブル対応」カテゴリにある完全な対応表を参照してください。
日常のブラウジングにはシステムプロキシモードで十分です。負荷が小さく、ドライバも不要です。コマンドラインツールやゲーム、システムのプロキシ設定を読まない一部のプログラムをプロキシ経由にしたい場合にのみ、TUNモードを有効にしてネットワーク層から丸ごと引き受けます。両モードの違いはコア機能詳細図 F-03 と設定大全の対応章で詳しく解説しています。
ルールモードはルールテーブルに従って各接続の振り先を決定する、推奨の常用モードです。グローバルモードはルールを無視し、すべてのトラフィックを現在選択中のノード経由にするもので、一時的な検証時のみ使用します。直接接続モードはすべてのトラフィックがプロキシを経由しません。日常はルールモードを保ち、分岐ロジックは設定ファイルの rules セクションで管理します。
使えます。サブスクリプションはノードを一括で読み込むための便利な手段の一つに過ぎず、クライアントは設定ファイルにノードのパラメータ(サーバーアドレス、ポート、プロトコル、パスワードなどの項目)を直接記述することにも対応しています。記述方法は設定大全のプロキシノードの章を参照してください。ローカルでのルール検証のみが目的なら、DIRECT出口だけで動作させることも可能です。
トラブル対応、上級設定、エコシステムに関する長文記事を日付の新しい順に掲載。ここでは最新3件を表示します。
全ノードがタイムアウトする場合と一部のノードだけがタイムアウトする場合では原因が異なります。サブスクリプションの有効性、ローカルの速度測定方法、ポートとプロトコルのパラメータ、システム時刻とファイアウォールの順に確認し、各ステップの判断基準と対処法を解説します。
詳細図を見る →国内外の分岐をテーマに、DOMAIN-SUFFIX、GEOIP、RULE-SETの組み合わせ方、ルールが上から順に照合される仕組み、そしてMATCHによるフォールバックとよくある誤記による取り逃しの問題を解説します。
詳細図を見る →システムプロキシのスイッチはオンなのにトラフィックが流れない場合、ブラウザとターミナルでは原因が全く異なります。ブラウザの拡張機能との衝突やシステムプロキシの登録状況、ターミナルで手動設定が必要な環境変数をそれぞれ確認し、検証用コマンドも紹介します。
詳細図を見る →