まず確認：タイムアウトは速度テスト中？ 実際の通信中？
クライアントの「プロキシ」画面を開き、現在のプロキシグループと選択中のノードを控えてから、「ログ」画面で失敗したリクエストを確認します。クライアントによって「プロキシグループ」「実行ログ」など名称が異なる場合があるため、実際の画面に合わせてください。まずは再インストールや、DNS・ルール・ポートの一斉変更は避けましょう。
ノードの速度テストでは通常、コアが指定ノード経由でテスト用URLにアクセスし、クライアントの設定に基づいて遅延を測定します。timeout と表示されても、分かるのは今回のテストが制限時間内に完了しなかったことだけです。テスト先にアクセスできない、DNS検索に失敗した、ノードとのハンドシェイクに失敗した場合も、同じ結果になることがあります。
- 速度テストはタイムアウトするが、Webページは開ける：テストURLとタイムアウト時間を先に確認し、ノードをすぐに削除しないでください。
- 速度テストでは遅延が表示されるが、特定のアプリが開けない：アプリごとのプロキシ設定、適用されたルール、アプリ独自のネットワーク設定を優先して確認します。
- 全ノードがタイムアウトし、プロキシ経由の通信がすべて失敗する：以下の順に共通部分を確認します。まず端末のネットワーク、次にサブスクリプションとDNSを確認してください。
- 特定のノードだけ失敗する：サーバーアドレスが異なる別のノードと比較します。設定全体をすぐに変更する必要はありません。
手順1：プロキシを停止し、端末のネットワークとVPN接続を確認
まずスマートフォンがプロキシなしでインターネットに接続できるか確認
- クライアントのホーム画面で接続を停止し、AndroidのステータスバーからVPNアイコンが消えたことを確認します。
- プロキシなしで普段アクセスできるWebサイトを開きます。公衆Wi-Fiで認証画面が表示された場合は、ログインを済ませてからクライアントを起動してください。
- Wi-Fiを切ってモバイルデータ通信に切り替え、同じノードをテストします。その後Wi-Fiに戻し、ほかの設定は変えずに再度確認します。
- 特定のWi-Fiだけで失敗する場合は、その違いを記録します。すぐに全ノードが使えないと判断しないでください。
AndroidのVpnServiceは、アプリが端末上にVPNインターフェースを作成するためのシステム機能です。一般的な個人利用環境では、同じユーザーで同時に有効にできるVPNサービスは通常1つです。別のVPN、ファイアウォール、VPNインターフェースを使うフィルタリングアプリが、Clashの接続を妨げることがあります。これらのサービスを停止してから、もう一度接続してください。
システム設定によるプロキシなし通信の遮断を確認
Androidの「設定」→「ネットワークとインターネット」→「VPN」→現在のクライアントの設定ボタンを開き、「常時接続VPN」と「VPNを使用しない接続をブロック」を確認します。機種によっては「接続と共有」に設定項目があります。ブロックが有効な状態でクライアントを停止すると、インターネットに接続できないことがありますが、Wi-Fi自体の障害とは限りません。プロキシなしで比較するには、この項目を一時的にオフにできます。テスト中は通信がプロキシを迂回する可能性があるため、終了後は必要に応じて元に戻してください。
画面ロック後にだけ切断される場合は、ロックを解除してサービスを再起動し、「設定」→「アプリ」→現在のクライアント→「バッテリー」でバックグラウンド動作の制限を確認します。この症状は、常に発生するノードのハンドシェイクタイムアウトとは分けて記録してください。
手順2：サブスクリプションの更新と設定の有効化を確認
「設定ファイル」画面を開き、現在のサブスクリプションを手動で更新して、更新時刻とエラーを確認します。サブスクリプションはノードやルールを取得するための設定元です。更新の失敗とプロキシ接続の失敗は別の問題です。古い設定が引き続き使える場合もあり、更新に成功しても、サブスクリプション内の全サーバーに接続できるとは限りません。
- 同じ名前の古いインポートファイルではなく、更新したばかりの設定が有効になっていることを確認します。
- サブスクリプション提供元の管理ページで、有効期限、残りの通信量、端末数や接続数の上限を確認します。
- 更新エラーを確認します。HTTP
401や403は通常、認証やアクセス制限に関係します。404はリクエスト先のアドレスが存在しないことを示します。具体的な原因はレスポンスの内容も確認してください。 - YAMLの解析エラーや未対応のプロキシタイプが表示された場合は、ノードの速度テストより先に設定の読み込みエラーを解決します。
YAMLはClashの設定でよく使われるテキスト形式で、インデントも構造の解析に使われます。サブスクリプションURLをノードのサーバーアドレスとして扱ったり、ログインページを設定ファイルとして保存したりしないでください。「ダウンロード済み」と表示された後に解析エラーが出る場合、クライアントが使える設定内容を取得できていない可能性があります。
手順3：ノードのドメインと接続先サイトの名前解決を切り分ける
DNSはドメイン名をIPアドレスに変換する仕組みです。プロキシ経由の通信では、最初にノードサーバーのドメインを解決し、その後に端末側またはリモート側で接続先サイトのドメインを解決する場合があります。どちらか一方でも失敗すると、画面上は接続タイムアウトと表示されることがあります。ログに出ているドメインがどちら側のものか確認してください。
| 確認できた現象 | まず確認する箇所 | 次に行うこと |
|---|---|---|
| ノードサーバーのドメインでホストが見つからない | 接続開始前のDNS経路 | 端末でそのドメインを名前解決できるか確認し、まだ接続できていないノードにDNSリクエストが依存していないか調べます。 |
| ノードとのハンドシェイクは成功するが、特定サイトへのアクセスで名前解決エラーが出る | 接続先ドメインのDNSとルール | 別のサイトでも比較し、DNS設定と接続ログを確認します。 |
| AndroidのプライベートDNSを有効にした場合だけ失敗する | システムのプライベートDNSに接続できるか | 一時的に「自動」に切り替え、同じネットワークで再テストします。 |
| ネットワークを切り替えても古い名前解決結果が使われる | アプリとコアのキャッシュ | サービスを停止して再起動し、同じリクエストをもう一度実行します。 |
Androidでは「設定」→「ネットワークとインターネット」→「プライベートDNS」でシステム設定を確認できます。プライベートDNSは通常、暗号化されたDNS over TLSを使用します。設定ファイル内のDNS over HTTPSとは別の設定です。システムのプライベートDNSを一時的に「自動」にするのは比較のためであり、クライアント内部のDNSが必ず復旧するわけではありません。
mihomoはClash設定エコシステムと互換性のあるプロキシコアの1つです。DNS設定では、proxy-server-nameserverでノードサーバーのドメインを解決するリゾルバーを指定でき、default-nameserverはDNSサーバー自体のドメイン解決など、初期接続時に使うリゾルバーを指定します。各フィールドが有効かどうかは、実際に使うコアの対応状況によります。クライアントの外側の名称だけで判断しないでください。すべてのDNSリクエストを接続できていないプロキシ経由にすると、起動時に依存関係が循環するおそれがあります。
インターネット上で見つけたIPアドレスに、ノードのドメインを安易に置き換えないでください。TLSのサーバー名検証やSNI、CDNやロードバランサーの振り分けでは、元のドメインが必要な場合があります。SNIはハンドシェイク時に接続先の名前をサーバーへ伝える情報です。IPアドレスに変更すると、TCP接続が確立してもTLSハンドシェイクが正しく完了しないことがあります。
手順4：システム時刻を合わせ、TLSエラーを確認
「設定」→「システム」→「日付と時刻」を開き、「日時を自動設定」と「タイムゾーンを自動設定」を有効にします。機種によっては「その他の設定」→「日付と時刻」にあります。日付、年、現在時刻が実際と一致していることを確認してから、接続を再起動します。
TLSは通信を暗号化し、サーバーの身元を確認するためのプロトコルです。証明書には有効期間があり、一部のプロキシプロトコルは時刻のずれにも影響されます。ログに certificate has expired or is not yet valid と表示された場合は、まず端末の時刻を確認し、その後サーバー証明書を調べます。このエラーだけでスマートフォンの時刻が原因と断定することはできません。
x509: certificate signed by unknown authority：証明書チェーンの不備、自己署名証明書、または通信経路上の機器による介入が考えられます。- 証明書の名前が一致しない場合は、ノードのドメインとサービス提供元が指定するサーバー名が一致しているか確認します。
- 時刻が正しいのに証明書エラーが続く場合は、ログを保存し、サービス提供元に証明書の設定と接続先アドレスを確認してもらいます。
エラーを消す目的で skip-cert-verify を常時有効にしないでください。証明書検証を省略するとサーバーの身元確認が弱まり、ポートの接続障害やプロトコルパラメーターの誤りも解決できません。
手順5：プロトコル、サーバーポート、コアの対応状況を確認
ノードの詳細画面でプロトコルの種類、サーバーアドレス、サーバーポートを確認し、クライアントの「バージョン情報」またはコア情報画面で実際のコアのバージョンを記録します。Clashのクライアントとコアは別のバージョンです。設定をインポートできても、実行中のコアがすべてのプロトコルやフィールドに対応しているとは限りません。
ローカルの待ち受けポートとリモートポートを混同しない
- ローカルポート：設定の
mixed-port: 7890など、端末上のアプリがHTTPまたはSOCKSプロキシに接続するためのポートです。7890はよくある例で、実際の設定を確認してください。 - サーバーポート：ノードの詳細にある
portで、リモートサーバーへの接続に使います。443の場合もあれば、サービス提供元が割り当てた別のポートの場合もあります。 - 管理ポート：
external-controllerは制御用インターフェースであり、ブラウザーからWebサイトへアクセスするためのプロキシ入口ではありません。
ローカルポートを7890から7891に変更しても、リモートサーバーのポートが遮断されている問題は解決しません。ログに address already in use と表示される場合は、ローカルポートが使用中でないか、サービスを二重に起動していないか確認してください。
通信方式を変えて比較する
Hysteria2やTUICなどのプロトコルはUDPに依存します。ネットワークによってはUDPが制限され、これらのノードだけ失敗してTCPベースのノードは動作することがあります。サービス提供元が明示しているTCPノードを選び、同じネットワークで比較してください。ノード設定のUDPスイッチをオフにしただけで、TCPに切り替わったと判断しないでください。
WebSocketまたはgRPCを使うノードでは、通信経路、Host、サービス名も確認してください。HTTP 400、404や異常なハンドシェイク応答は、入口のパラメーターが一致していない場合や、サーバー側のリバースプロキシ設定に問題がある場合に発生します。現在のコアに対応したサブスクリプションを再取得し、フィールドを推測で変更しないでください。
手順6：実際の通信が正しいプロキシグループを通っているか確認
「接続」画面を開き、ブラウザーで対象サイトにもう一度アクセスします。該当リクエストが表示されるか、適用されたルール、プロキシグループ、最終的なノードを確認してください。Ruleモードでは設定ルールに基づいて直接接続またはプロキシ接続が選ばれます。選択中のノードが影響するのは該当するプロキシグループだけで、すべてのDIRECTルールを上書きするわけではありません。
- リクエストが表示されない場合は、Androidのアプリごとのプロキシ設定でブラウザーが除外されていないか確認し、VPNサービスが実際に動作中か確認してください。
- リクエストが
DIRECTに一致した場合は、プロキシグループ内のノードを何度も切り替えるのではなく、該当するルールを先に確認します。 - リクエストが別のプロキシグループに入った場合は、そのグループで実際に選択されている項目を確認します。グループ内で
DIRECTや古いノードが選択されたままの場合があります。 - 比較のため、一時的にGlobalモードへ切り替え、明確なノードを1つ選ぶ方法もあります。テスト後はRuleモードに戻し、一時的な状態を最終設定として残さないでください。
Globalモードはプロキシの選択を比較するためのもので、端末の全通信を必ず取り込むわけではありません。アプリごとの設定で除外されたアプリや、そもそもプロキシインターフェースに入っていない通信は、モードを切り替えても表示されません。デスクトップ版のTUNは仮想ネットワークインターフェースで通信を取り込む方式で、Androidクライアントは通常VpnServiceで通信を受け取ります。どちらも停止したサーバーや誤った認証情報は修復できません。
デスクトップ版での補助確認：ローカルプロキシポートを指定
同じサブスクリプションをパソコンでも使っている場合は、パソコンのターミナルで次のコマンドを実行できます。例ではパソコンのクライアントのHTTPまたはmixedポートが7890で、テスト先の https://example.com/ にアクセスできることを前提としています。テスト先自体が利用可能である必要があります。これはAndroid標準のテスト手順ではありません。
curl --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/127.0.0.1 は常にコマンドを実行している端末自身を示します。パソコンで実行したコマンドが、スマートフォンのクライアントに自動で接続することはありません。他の端末から接続するには、LAN側の待ち受け設定とアクセス制御が必要になります。今回のトラブル対処では、追加で有効にしないことをおすすめします。コマンドでHTTPレスポンスを取得できても、そのテスト経路が使えることを示すだけで、すべてのアプリがプロキシを経由している証明にはなりません。
ログエラーの早見表：接続経路で最初に失敗した箇所を確認
「ログ」画面で一時的にログレベルを info に設定し、情報が足りない場合だけ短時間 debug を使います。リクエストの時刻を記録してから再現し、その前後のログを保存します。コアによって表示内容は異なります。以下の表は確認の方向を示すもので、前後のログ全体の代わりにはなりません。
| ログの例 | 一般的な意味 | 次に確認する項目 |
|---|---|---|
lookup … no such host | ドメインの名前解決で有効なレコードを取得できない | ノードのドメインか接続先のドメインか、DNSがどのような応答を返したか |
dial tcp … i/o timeout | 指定アドレスへのTCP接続が時間内に確立しなかった | サーバーアドレス、ポート、現在のネットワーク、リモート側の状態 |
connection refused | 接続要求に対して拒否応答が返された | 接続先ポートでサービスが待ち受けているか、ファイアウォールが明示的に拒否していないか |
TLS handshake timeout | TLSハンドシェイクが制限時間内に完了しなかった | 通信経路のパケットロス、サーバー負荷、TLSの接続先、名前の指定 |
authentication failed | 認証に失敗した | サブスクリプションの状態、パスワードまたはUUID、プロトコルの要件 |
connection reset by peer | 相手側または通信経路上の機器によって接続がリセットされた | プロトコルのパラメーター、サーバーログ、ネットワークを切り替えた場合の違い |
EOF | 読み込み中に接続が終了した | 前段のハンドシェイクや認証のエラーを確認します。この行だけでは原因を特定できません。 |
たとえば、ノードのドメイン解決に失敗した後でテストがタイムアウトした場合は、まずDNSを解決します。最後に表示されたタイムアウトだけを唯一の原因と見なさないでください。トラブル対処後は通常使うログレベルに戻し、アクセス記録を大量に残したままにしないようにします。
すべてタイムアウトする場合：再現可能な情報をまとめて報告
プロキシなしの通信が正常で、サブスクリプションが有効、時刻も正しく、さらに異なる2台以上のサーバーがWi-Fiとモバイルデータの両方で失敗する場合は、証拠をサブスクリプション提供元またはクライアントの開発者に共有してください。複数のノードが同じ入口ドメインを使っている場合、サーバーごとの独立した比較にはなりません。
- 環境：Androidのバージョン、クライアント名とバージョン、コア名とバージョンを実際の画面に合わせて記入します。
- 発生時刻：失敗した日付、時刻（時・分）、タイムゾーンを記入すると、サーバー側の記録と照合しやすくなります。
- 発生範囲：全ノードか特定のノードだけか、速度テストの失敗か実際のWebページへのアクセス失敗かを記載します。
- ネットワークごとの差：Wi-Fiとモバイルデータでそれぞれ3回テストした結果と、公衆ネットワークの認証が完了しているかを記載します。
- ログ：最初のエラー前後に必要な行を添付し、サブスクリプションのトークン、認証情報、個人用のアクセスドメインは伏せます。
- 確認済みの項目：サブスクリプションの更新結果、システム時刻、DNSの比較結果、プロトコルの種類を記載し、同じ確認の繰り返しを避けます。
トラブル対処が終わったら、一時的に変更したログレベル、プロキシモード、プライベートDNS、システムのVPNブロック設定を元に戻します。問題を再現できる最小限の手順を残すほうが、設定を重ねて変更し続けるより原因を特定しやすくなります。