Mihomoのよくある質問

Mihomoはプロキシ接続、DNS、ルール判定を処理するコアです。一方、GUIクライアントは設定のインポート、プロキシグループの選択、システムプロキシの設定などを行う画面を提供します。同じコアを使っていても、クライアントによってメニュー名や権限の要求、設定の統合方法は異なります。手順を調べるときは、まずクライアント名を確認し、設定画面やログでコアの情報を確かめてください。設定項目が認識されない場合は、実際のコアのバージョンに対応するドキュメントを確認しましょう。画面の見た目だけで機能の対応状況を判断することはできません。一般的なデスクトップ利用ではGUIクライアントが便利です。コア単体のパッケージは主にコマンドライン、サーバー、ルーターでの運用に使われます。

クライアントは設定を実行するもので、利用可能なリモートプロキシサービスを自動で提供するわけではありません。サブスクリプションURLは通常、サービス提供元が発行し、ノードやプロキシグループ、ルールなどを取得するために使います。ローカルのYAMLファイルに同様の設定を記述することもできます。インポート前に設定がMihomoに対応していることを確認してください。サービス提供元のWebページやログイン画面のURLは、サブスクリプションURLとは異なります。URLに認証情報が含まれる場合があるため、アカウント情報と同様に管理し、公開画像やグループチャット、コードリポジトリに載せないでください。漏えいした場合は提供元の管理画面で再発行し、各デバイスに保存したURLも更新しましょう。

ルールモードは、設定されたルールの順序に従って、通信を直接接続するか、プロキシグループなどのポリシーに振り分けます。日常的な通信の振り分けに適しています。グローバルモードでは、コアが処理する通信にグローバルポリシーを適用します。ルールがアクセスに影響しているか、一時的に比較するときに便利です。DIRECTモードでは、対象の通信を直接接続します。モードが決めるのは、コアが受け取った通信の処理方法です。すべてのアプリの通信がコアに届いていることを意味するわけではありません。システムプロキシとTUNは、通信を取り込む方法を決めます。原因を調べるときは、一時的にグローバルモードに切り替えて利用可能なノードを選び、テスト後にルールモードへ戻してください。一時的な設定をそのまま使い続けないようにしましょう。

UDPを転送できるかどうかは、アプリの通信がコアに届いているか、ノード設定でUDPが有効か、プロキシプロトコルとサーバーがUDPに対応しているか、ネットワークが該当するパケットを通すかなど、経路全体に左右されます。クライアントでノードが利用可能と表示されたり、Webページが開いたりしても、一部の接続が成立したことを示すだけで、実際のUDP通信を確認したことにはなりません。ゲームや通話ではDNS、DIRECTポリシー、NAT環境も関係する場合があります。まずアプリの通信を取り込む方法を確認し、次に適用されたプロキシグループとノードを調べ、最後にアプリ上で実際にテストしてください。UDPの設定を有効にするだけでは、サーバー側にない機能を補うことはできません。

まず更新ログでHTTPステータスとエラー内容を確認してください。401は認証情報がない、または無効になっている場合によく発生します。403はアクセス制限、プランの状態、サーバー側のポリシーなどが原因として考えられるため、提供元の案内も確認しましょう。管理画面からサブスクリプションURLをもう一度コピーし、クエリパラメーターの欠落や余分な空白、WebページのURLをコピーしていないかを確認してください。URLにアクセスできてもYAMLエラーが出る場合は、返された内容がログイン画面やエラーページではないか確認します。ダウンロードの失敗と設定の解析エラーを区別してから対処し、現在使えている設定を何度も削除しないでください。以前の設定は一時的な復旧用に残しておけます。

TUNは仮想ネットワークインターフェースの作成とルーティングの変更が必要なため、通常はシステムプロキシより多くの権限を必要とします。Windowsでは、クライアントのサービスモードがインストール済みで、実行中か確認し、クライアントの案内に従って管理者権限を許可してください。ルートを制御するプロキシツールを複数同時に起動しないようにしましょう。macOSでは使用中のクライアントの説明に従い、システムの許可設定や補助サービスを確認します。表示されるすべてのダイアログを同じネットワーク拡張の要求とみなさないでください。許可した後にTUNを再度有効にし、最初に記録されたエラーログを確認します。インターフェースを作成できない場合は、TUNを無効にしてシステムプロキシが使えるか確認し、そのうえで権限、ドライバー、ルーティングを個別に調べてください。

デバイスの発売時期から推測せず、OSに表示されるハードウェア情報を確認してください。Windowsでは設定のシステム情報からシステムの種類を確認できます。一般的なIntelまたはAMD搭載PCはx64ですが、ARMデバイスではクライアントが対応するインストーラーを提供しているか確認が必要です。macOSでは「このMacについて」でAppleシリコンかIntelプロセッサかを確認し、対応するアーキテクチャを選んでください。アーキテクチャが合わないと起動できなかったり、OSの変換機能が必要になったりします。更新前に設定をバックアップし、起動中の旧バージョンを終了してください。インストーラーにOSのバージョンが要件を満たさないと表示された場合は、繰り返しインストールするのではなく、クライアントのリリースノートを確認しましょう。

Androidクライアントは、VpnServiceを使って端末の通信を取り込むことが多く、初回接続時にシステムのVPN利用を許可する必要があります。この許可はローカルVPNインターフェースの作成を認めるもので、サーバーのノードが利用可能であることを示すものではありません。同じユーザー環境で有効にできるVPNは通常1つだけです。別のVPNツールを起動すると、現在の接続が切断される場合があります。バックグラウンドで切断される場合は、まずバッテリー使用量、バックグラウンド動作、自動起動がシステムに制限されていないか確認し、端末の設定でクライアントを許可してください。プロセスの終了とノードの接続失敗も区別しましょう。前者では通知が消えることが多く、後者ではログやサブスクリプションの状態を確認する必要があります。

システムプロキシは、システム設定に従うアプリにプロキシのアドレスを通知するもので、すべてのネットワーク接続を強制的に取り込むわけではありません。まずシステム設定のアドレスとポートが、クライアントの実際の待ち受け先と一致するか確認します。次に、アプリ独自のプロキシ設定、ブラウザー拡張機能、環境変数、個別のネットワーク設定が使われていないか確認してください。テスト時はクライアントの接続一覧を開き、新しいリクエストが表示されるか確認します。記録がない場合は、振り分けルールを変更する前に通信の取り込み方法を見直しましょう。システムプロキシに従わないアプリでは、必要に応じてアプリ内プロキシまたはTUNを設定してください。取り込み方法を切り替えるときは、複数の設定が重なって経路を特定しにくくならないよう、競合する設定を先に無効にしましょう。

AppContainerのネットワーク分離の影響を受ける一部のWindowsアプリは、ローカルループバックのプロキシに直接アクセスできません。そのため、ブラウザーが正常に動いていても、対象アプリが接続できるとは限りません。まずアプリが実際にこの制限を受けていることを確認してください。そのうえで、クライアント付属のループバック免除ツール、またはWindowsのCheckNetIsolationを使って、対象アプリの免除状態を確認・管理します。必要なアプリだけを許可し、すべてのアプリをまとめて許可しないでください。変更後に対象アプリを再起動し、接続記録を確認します。ループバックの免除で解決できるのは、ローカルプロキシへのアクセス制限だけです。サブスクリプションの無効化、DNSエラー、リモートノードのタイムアウトは解決できません。また、ストアアプリすべてに設定が必要なわけではありません。

一般的な遅延テストで測定するのは、指定したテスト先へのアクセスにかかる時間であり、継続的なダウンロード速度ではありません。テスト先、タイムアウト値、キャッシュ、ノードから接続先までの経路などが結果に影響します。ノードを選ぶときは、同じテスト先を同じ時間帯に近い条件で比較し、実際に利用するサービスでも速度を確認してください。ダウンロード速度は、サーバー側の速度制限、出口回線の混雑、Wi-Fiの品質、接続先の制限にも左右されます。1回の遅延測定だけで順位を決めて頻繁にノードを切り替えないようにしましょう。既存の接続は元のノードを使い続け、新しい接続から選択したノードに切り替わる場合があります。それぞれ分けて確認してください。

Fake-IPモードは、ドメイン名と後続の接続を対応付けるためにマッピングアドレスを使い、クライアントはドメイン名とルールに基づいてリクエストを処理します。これらのアドレスは接続先の実際のグローバルIPアドレスではないため、通常の直接接続用アドレスと同じ方法で到達性を判断できません。LAN機器の検出、特定のログインプログラム、実際の名前解決結果に依存するアプリで問題が起きた場合は、まずDNSリクエストがMihomoに届いているか確認します。次に、該当するドメインについてfake-ip-filterや名前解決のポリシーを確認してください。すべてのドメインを安易にフィルターへ追加しないでください。変更後はOSやアプリのDNSキャッシュをクリアし、接続を張り直す必要がある場合があります。比較できるよう、変更前の設定を保存しておきましょう。

まずプロキシを無効にして、通常のネットワーク接続が正常か確認してください。次に、端末の時刻、サブスクリプションの更新状況、プランやノードの有効状態を確認します。タイムアウトするノードが1つだけなら、同じサブスクリプションの別ノードと比較してください。すべてのノードで発生する場合は、ネットワークの出口、設定エラー、サービス提供元の稼働状況を優先して確認します。ログでは、ドメイン名の解決失敗、接続拒否、認証失敗、ハンドシェイクのタイムアウトを区別してください。それぞれ対処方法が異なります。テスト先自体にアクセスできないと遅延テストが失敗することもあるため、実際に利用するサービスでも試してください。最初からポート、DNS、ルールを同時に変更せず、1つずつ変更して結果を記録しましょう。

接続済みの表示は、コアやローカルVPNインターフェースが起動したことを示すだけで、接続先へのリクエストが完了するとは限りません。まず接続一覧にブラウザーのリクエストが表示されるか確認します。記録がなければ、システムプロキシ、アプリ内プロキシ、TUNによる取り込みを確認してください。記録がある場合は、適用されたルール、プロキシグループ、ノードを確認します。次にログを見て、DNSの失敗とリモート接続の失敗を区別し、一時的にグローバルモードと別の利用可能なノードで比較してください。ノードを切り替えて直った場合は、元のノードを重点的に確認します。特定のドメインだけで問題が起きる場合は、ルールと名前解決を調べましょう。ブラウザーが古い接続を再利用して判断に影響しないよう、テストのたびに新しい接続を開始してください。

まずルールモードが選択されていることを確認し、エディターに保存されたファイルだけでなく、実際に適用中の設定を調べてください。クライアントによってはサブスクリプション、オーバーライド、ローカルルールを統合するため、更新後に最終的な内容が変わる場合があります。Mihomoはルールを上から順に照合します。前方にある広範なルールやMATCHによって、後続のルールに到達しないことがあります。具体的なドメインに新しいリクエストを送り、接続の詳細で一致したルールとポリシーを確認してください。既存の長時間接続はルールの変更後も自動で切り替わらないことが多いため、該当する接続を閉じてから再試行します。独自ルールを長期的に保持するには、クライアントが対応しているオーバーライドや設定統合の仕組みを利用してください。

まずクライアントを再起動し、システムプロキシとTUNを無効にしてから、通常の手順で終了してください。プロセスを強制終了すると、通信の取り込み設定が残ることがあります。その後、システムのネットワーク設定がローカルのプロキシポートを参照したままになっていないか確認します。コアが停止している状態では、そのアドレスは利用できません。DNSを手動設定していた場合は、元の値を記録してから、現在のネットワークに合わせて戻してください。他のプロキシツールやVPNが同時に動作していないことも確認します。設定を1つ戻すたびに接続をテストし、すぐにネットワーク全体をリセットしないでください。スリープからの復帰後やネットワーク切り替え後だけ問題が起きる場合は、発生時刻、インターフェースの状態、ログを記録し、クライアントの更新情報を確認しましょう。