Clashの混合ポートとLANプロキシ：スマホや他の端末で共有する設定

共有プロキシの通信経路

パソコンでClashまたはMihomoを起動すると、1つ以上のローカルプロキシ待ち受けポートが作成されます。通常、これらのポートはパソコン上のアプリだけが利用します。LANアクセスを有効にすると、同じネットワーク上のスマホ、タブレット、テレビボックス、別のパソコンからもこの待ち受けポートへリクエストを送信でき、Clashを実行しているホストがルール判定とノードへの転送を行います。

通信経路全体は次のように整理できます。クライアント端末がリクエストを開始し、家庭用ルーターやLANスイッチがデータをClashホストへ渡します。Clashは現在のモードとルールに基づいて、プロキシノードを使うか直接接続するかを決定し、レスポンスは同じ経路を戻ります。リモート端末がClashの設定ファイルを読み込む必要はなく、サブスクリプション内のノードへ直接接続することもありません。必要なのは、ホストのLAN IP、待ち受けポート、プロキシプロトコルだけです。

この共有方式は、パソコンを完全なルーターに変えるものではありません。HTTPプロキシを手動設定した場合、システムプロキシ設定に従うアプリだけがClashを経由します。システムプロキシを無視するアプリ、直接接続するアプリ、自前のVPNインターフェースを使うアプリは、そのまま直接接続する可能性があります。端末の全トラフィックを引き受ける必要がある場合は、透過プロキシやTUN対応クライアントを端末側に導入するか、サイドルーターを利用してください。Wi-Fiのプロキシ欄だけに依存する方法では不十分です。

mixed-portでHTTPとSOCKS5を同時に受け付ける

mixed-portは混合プロキシポートです。HTTPプロキシ接続とSOCKS5プロキシ接続を同じポートで受け付けられるため、portとsocks-portを別々に管理する手間を減らせます。一般的なポート番号は7890ですが、慣例的な設定値にすぎず、固定ではありません。他のプログラムが使用していなければ、未使用の別ポートに変更できます。

mixed-port: 7890
allow-lan: true
bind-address: "*"
mode: rule
log-level: info

この設定は、7890番ポートでHTTPとSOCKS5のリクエストを受け付け、LAN内の端末からの接続を許可し、ルールモードでトラフィックを処理することを示します。YAMLはインデントと文字形式の影響を受けやすいため、コロンの後にはスペースを残してください。アスタリスクはYAMLのエイリアス構文として解釈されないよう、引用符で囲むことをおすすめします。

設定にport、socks-port、mixed-portを同時に残している場合は、クライアント画面から最終的にカーネルへ書き込まれる値を確認してください。異なるポートを併用することはできますが、スマホに入力するポートは実際に待ち受けているポートと一致していなければなりません。GUIクライアントの「混合ポート」「LAN接続を許可」といった項目は通常これらのフィールドに対応します。変更後に設定の適用やカーネルの再起動が必要になる場合もあります。

HTTPとSOCKS5はどちらを選ぶべきか

スマホのWi-Fi設定にある「プロキシ」は通常HTTPプロキシを指すため、ClashホストのLAN IPとmixed-portを入力します。ブラウザーでHTTPSサイトへアクセスする場合も、HTTP CONNECTでトンネルを確立できるため、このポートを利用できます。SOCKS5に対応するアプリでは、同じアドレスとポートをSOCKS5サーバーとして指定できます。

HTTPプロキシはシステムのネットワーク設定から導入しやすい一方、すべてのアプリが従うとは限りません。SOCKS5はより多くのアプリ層接続を扱え、プロキシ側で名前解決する使い方にも対応しますが、システム設定画面にSOCKS5の入力欄がないことも多く、アプリ内の設定が必要です。共有経路だけを確認したい場合は、まずHTTPプロキシで試すのが分かりやすいでしょう。

共有リクエストもルールシステムを通る

リモート端末が混合ポートへ接続しても、リクエストが自動的にグローバルプロキシへ入るわけではありません。Clashは現在のルールモード、グローバルモード、ダイレクトモードに従ってトラフィックを処理します。ルールモードでは、ドメイン、宛先IP、プロセスを特定できない場合のネットワーク上の特徴、設定内のルール順序が最終的なポリシーに影響します。テストサイトがDIRECTに一致した場合、共有設定が正しくても出口IPが変わらないことがあります。

切り分けでは、ページを開けるかどうかだけでプロキシの有効性を判断せず、接続一覧やログでルールの一致結果を一時的に確認してください。検証が終わったら、普段使うモードへ戻し、グローバルモードでルール設定の問題を隠したままにしないようにします。

LANアクセスの許可と待ち受けアドレス

allow-lan: trueは、他の端末がプロキシポートへアクセスできるかどうかを制御します。混合ポートだけを設定してLANアクセスを許可していない場合、カーネルはホスト自身からの接続しか受け付けず、スマホでは接続タイムアウトや即時拒否として現れることがあります。GUIクライアントでは「LANを許可」「LAN接続」「Allow LAN」などの名前で表示されます。

bind-addressは、どのローカルアドレスで待ち受けるかを決めます。"*"は、実装に従って利用可能なアドレスで待ち受ける指定で、ホストのアドレスが変わりやすい家庭内ネットワークに適しています。IPv4だけを共有する場合は、すべてのIPv4インターフェースで待ち受ける0.0.0.0も利用できます。待ち受け範囲を絞るなら、ホストの現在のLAN IPv4アドレス、たとえば192.168.1.20を指定します。ただし、DHCPでアドレスが再割り当てされた場合は設定も更新が必要です。

クライアント端末には127.0.0.1、localhost、0.0.0.0を入力しないでください。スマホ上の127.0.0.1はスマホ自身を指します。0.0.0.0は待ち受け用のワイルドカードアドレスであり、接続先としては使えません。スマホのプロキシサーバー欄には、Clashを実行しているパソコンの現在のLAN内アドレスを入力します。

ホストのLAN IPを調べる

• Windowsではipconfigを実行し、現在接続しているWi-FiまたはEthernetアダプターのIPv4アドレスを確認します。
• macOSではネットワーク設定で接続中のインターフェースのIPを確認できます。ipconfig getifaddr en0も使えますが、インターフェースがen0でない場合は実際の名前に置き換えてください。
• Linuxではip addrを実行し、現在ネットワークに接続しているインターフェースからLANアドレスを探します。

家庭内でよく使われるアドレスは、192.168.、10.、または172.16.から172.31.で始まります。ホストには有線NIC、無線NIC、仮想マシン用NIC、VPN仮想インターフェースが同時に存在することがあります。スマホと同じLANに接続している物理インターフェースのアドレスを選んでください。最も簡単なのは、2台のデバイスのゲートウェイとサブネットを比較する方法です。

ファイアウォールの許可とWi-Fiクライアント分離

カーネルがLANアドレスで待ち受けていても、データがポートまで到達するとは限りません。Windows Defenderファイアウォール、macOSファイアウォール、Linuxのnftables、iptables、firewalldはいずれも受信接続を遮断する可能性があります。許可ルールは実際に使うTCPポートを対象とし、送信元はできるだけ家庭内または社内LANのサブネットに限定してください。

Windowsでは、関連クライアントを初めて起動した際に、どの種類のネットワークで通信を許可するか尋ねられることがあります。通常は「プライベートネットワーク」だけを許可すれば十分です。現在のWi-Fiがパブリックネットワークとして認識されていると、アプリにプライベートネットワークの権限があっても接続が遮断される場合があります。まずネットワークプロファイルの種類を確認し、アプリのルールやポートルールが現在のカーネルプロセスを対象にしているか確認してください。

Linuxホストでは、まず待ち受け状態を確認してからファイアウォールを調べます。たとえば次のコマンドで7890番ポートを確認できます。

ss -lnt | grep 7890

結果が127.0.0.1:7890だけを示す場合、問題はClashの待ち受け設定にあります。0.0.0.0:7890、ホストのLANアドレス、または対応するIPv6待ち受けアドレスが表示される場合は、ファイアウォールとルーターの分離設定を確認します。テストのためにファイアウォールをすべて無効にするのは避け、範囲を明確にした一時的な受信ルールを作るほうが原因を特定しやすく、テスト後の撤回も容易です。

同じWi-Fiでも端末間通信ができない場合がある

一部のルーターでは、ゲストネットワークにAP分離、クライアント分離、無線端末分離が有効になっています。この場合、スマホとパソコンが同じルーターに接続しているように見えても、LAN接続を直接確立できません。企業、ホテル、公共ホットスポットでも同様の設定が使われます。別のパソコンからプロキシポートへ接続してみるか、スマホからホスト上の別のLANサービスへ接続できるか確認してください。

デュアルバンドWi-Fi自体が通信を遮断することは通常ありませんが、ルーターによってはゲストSSID、IoT用SSID、メインネットワークを異なるサブネットに分けています。端末のアドレスが同じサブネットにない場合は、サブネット間通信が許可されているかルーターを確認してください。allow-lanを有効にするだけでは、ルーターのアクセス制御を回避できません。

スマホ、タブレット、別のパソコンでの設定方法

iPhoneとiPad

1. Clashホストと同じWi-Fiに接続し、端末間通信が許可されていることを確認します。
2. 現在接続しているWi-Fiの詳細設定を開き、「HTTPプロキシ」に進んで設定方式を「手動」に変更します。
3. サーバーにはClashホストのLAN IPを、ポートにはmixed-portの値を入力します。
4. カーネルでプロキシ認証を設定している場合は、対応するユーザー名とパスワードも入力します。設定していない場合は認証をオフのままにしてください。
5. 保存後、プロキシルールに一致するはずのサイトをブラウザーで開き、Clashの接続一覧も同時に確認します。

iOSとiPadOSの手動HTTPプロキシ設定はWi-Fiネットワークごとに保存されます。モバイルデータ通信や別のWi-Fiへ切り替えた場合、または現在のネットワークを切断した場合、この設定は自動的に引き継がれません。一部のアプリはシステムHTTPプロキシを無視するため、ブラウザーで成功してもすべてのアプリが同じ経路を使うとは限りません。

Android端末

1. 現在接続しているWi-Fiのネットワーク変更または詳細設定画面を開きます。
2. プロキシ方式を「手動」に変更し、プロキシのホスト名にパソコンのLAN IPを入力します。
3. プロキシポートには混合ポートを入力します。例：7890。
4. 保存してWi-Fiに再接続し、ブラウザーとClashのログでリクエストを確認します。

Androidはメーカーによって設定画面の名称が異なり、Wi-Fi名を長押ししないとプロキシ項目が表示されないシステムもあります。システムレベルのWi-Fi HTTPプロキシは通常すべてのアプリをカバーせず、VPNやTUNと同じものでもありません。SOCKS5を使うアプリでは、アプリ内に同じホストアドレスと混合ポートを入力し、SOCKS5プロトコルを選択してください。

別のパソコン

Windows、macOS、Linuxでは、システムのネットワークプロキシにHTTPプロキシを入力できます。ブラウザー、ターミナル、開発ツールだけに設定することも可能です。curlでHTTPプロキシを確認する場合は、次を実行します。

curl -x http://192.168.1.20:7890 https://example.com

SOCKS5を確認し、名前解決をプロキシ側で処理する場合は、次を実行します。

curl --socks5-hostname 192.168.1.20:7890 https://example.com

例にあるIPは実際のホストアドレスに置き換えてください。最初のコマンドは成功するのにシステム上のアプリが失敗する場合は、アプリがシステムプロキシを読み取るか、プロキシバイパスリストが設定されているか、アプリが別のネットワークトンネルを独自に確立していないかを重点的に確認します。

アクセス制御、認証、公開範囲

すべてのインターフェースで待ち受けると、到達可能な同一ネットワーク上の他の端末がプロキシポートへ接続を試みられます。信頼できる家庭内ネットワークでは、ファイアウォールで送信元サブネットを制限できます。利用者の多いオフィス、寮、公共ホットスポットでは、待ち受けアドレスをさらに限定するか、カーネルが対応するプロキシ認証を利用してください。

Mihomoなどの実装では、設定によってHTTPおよびSOCKSの入口にユーザー名とパスワードを設定できます。一般的な設定例は次のとおりです。

authentication:
  - "lanuser:replace-with-a-strong-password"

認証フィールドの対応状況はカーネルやクライアントのバージョンによって異なります。変更前に、現在のクライアントが実際に使用しているカーネルを確認してください。ユーザー名とパスワードはプロキシを利用する端末へ渡すことになるため、LANアクセス制御の一部として有効ですが、ファイアウォールによる送信元制限も必ず併用してください。プロキシポートをルーターのグローバルアドレスへポートマッピングしたり、クラウドホストのセキュリティグループでインターネットに公開したりしないでください。

自宅でたまに共有するだけなら、使用後に「LANを許可」を無効にするか、一時的なファイアウォールルールを削除します。長期的に共有する場合は、ホストIPを固定し、ポートの用途を記録してください。開発サーバー、データベース、その他のローカルサービスと同じポートを使うのも避けましょう。

共有できないときの確認手順

切り分けは待ち受け側からクライアント側へ、段階を追って進めます。一度に変更する項目は1つにし、各段階の現象を記録してください。ノードを何度も切り替えたり、クライアントを再インストールしたりするだけでは、LAN接続の問題を特定できないことが多いです。

手順1：カーネルの動作とポートの使用状況を確認する

まずホスト自身で127.0.0.1と混合ポートを使い、プロキシをテストします。ホスト上でも接続できない場合は、カーネルが起動しているか、設定の読み込みに成功しているか、ポートを他のプログラムが使用していないか、ログにYAML解析エラーや待ち受け失敗がないかを確認します。ポートが競合している場合は未使用の新しいポートを選び、リモート端末の設定も合わせて変更してください。

手順2：待ち受け範囲を確認する

allow-lanがtrueになっているか確認し、実際の待ち受けアドレスも調べます。ループバックアドレスだけで待ち受けている場合、NICからリクエストを受け取れません。GUIクライアントの項目を変更した後は、有効な設定へ書き込まれていることを確認してください。使用していない設定ファイルを変更しただけでは反映されません。

手順3：IP、ポート、ネットワークを確認する

スマホに入力したアドレスが、ゲートウェイ、仮想NIC、前回接続時の古いアドレスではなく、ホストの現在のLAN IPであることを確認します。2台の端末が相互通信を許可したネットワークに接続していることを確認し、ネットワーク経路を切り替えるモバイルデータ通信の補助機能をオフにしてから再テストします。ルーターでゲスト分離が有効な場合は、メインネットワークへ切り替えるか分離ポリシーを調整してください。

手順4：ファイアウォールを確認する

ポートは待ち受けているのにリモート接続がタイムアウトする場合、受信ファイアウォールが原因であることが多いです。対象TCPポートへのアクセスをローカルサブネットだけに許可するルールを作成し、別のパソコンからポートの疎通をテストします。Windowsでは、リモート側のPowerShellで次を実行できます。

Test-NetConnection 192.168.1.20 -Port 7890

TcpTestSucceededが真なら、TCPポートへ到達できることを示すだけで、プロキシルールやノードが動作しているとは限りません。偽の場合は、アドレス、待ち受け、ファイアウォール、ネットワーク分離を引き続き確認します。

手順5：接続とルールの一致を確認する

ポートには到達できるのにウェブページが開かない場合は、Clashの実行ログまたは接続一覧を開きます。新しい接続がまったく表示されないなら、クライアントアプリがシステムプロキシを使っていないか、プロキシ設定が保存されていない可能性があります。接続は表示されるものの失敗する場合は、名前解決、ノードの状態、ポリシーグループの選択、ルールの一致結果を確認します。

ルールモードでは、テスト対象がダイレクト接続に一致する可能性があります。グローバルモードでは、現在のグローバルポリシーが利用できないノードを指していることがあります。ダイレクトモードでは、すべてのリクエストがプロキシノードを迂回します。モードとポリシーグループは転送層の問題であり、LANポートへ到達できるかどうかとは分けて判断してください。

手順6：HTTP、DNS、UDPの制限を切り分ける

スマホのWi-Fiに設定したHTTPプロキシは、主にHTTPプロキシ方式を使うTCPリクエストを処理します。アプリが独自に送信するDNS、QUIC、ゲームのUDP、その他システムプロキシを読み取らない通信は、このポートを通らない可能性があります。「ブラウザーは使えるが、特定のアプリは使えない」場合は、共有が失敗したとすぐに判断せず、そのアプリがどのプロキシ方式に対応しているか確認してください。

SOCKS5クライアントに「リモートで名前解決」といった項目がある場合は有効にすると、プロキシ側で対象ドメインを解決でき、クライアント側DNSによる差異を減らせます。HTTP CONNECTリクエストもドメインをプロキシ側へ渡す場合がありますが、具体的な挙動はクライアントの実装によります。UDPを使うアプリには、クライアント、入口プロトコル、ノード、ファイアウォールのすべてが対応している必要があり、通常のウェブページのテスト結果だけでは判断できません。

設定完了後の確認リスト

1. ホスト上でmixed-portを使い、正常にネットワークへアクセスできる。
2. allow-lanが有効で、ポートが127.0.0.1だけで待ち受けていない。
3. スマホにはホストの現在のLAN IPと正しいポートを入力している。
4. ファイアウォールは必要なローカルサブネットからの受信接続だけを許可している。
5. ルーターで2台の端末にクライアント分離が設定されていない。
6. Clashの接続一覧に、LAN内端末からの新しいリクエストが表示される。
7. テスト対象が意図したルールとポリシーグループに一致し、誤ってダイレクト接続になっていない。
8. 使用後は必要に応じてLANアクセスを無効にするか、制限付きルールを維持する。

混合ポート共有の要点は、単一のスイッチではなく、入口、ネットワーク、転送の3層を同時に成立させることです。Clashが正しく待ち受け、LANから到達でき、ルールとノードが後続の接続を処理できなければなりません。この順番で確認すれば、「スマホからプロキシに接続できない」問題を、ポート、ノード、システム設定の間で試行錯誤するのではなく、明確な設定項目に分解できます。