mixed-port と allow-lan の設定ガイド：LAN内のデバイスでプロキシを共有する方法

まず mixed-port、port、socks-port の違いを整理する

mihomo は HTTP、SOCKS5、混合プロキシの入口を同時に提供できます。最終的にはすべて同じプロキシルールとポリシーグループに接続されますが、クライアントが接続する入口は異なります。LAN内で共有する場合、通常は mixed-port を1つ開放するのが最も手軽です。スマホでは HTTP プロキシポートとして入力でき、SOCKS5 に対応したアプリも同じポートへ接続できるため、サーバー側で接続プロトコルが判別されます。

設定項目	代表的なポート	接続プロトコル	適した場面
`mixed-port`	`7890`	HTTP と SOCKS5	LAN内の入口を1つだけ管理したい場合
`port`	`7890`	HTTP	システムプロキシ、ブラウザー、テレビボックスに HTTP プロキシ欄しかない場合
`socks-port`	`7891`	SOCKS5	アプリが SOCKS5 に対応している場合、または UDP 機能が必要な場合
`redir-port`	`7892`	透過転送の入口	Linux のルーティングルールでリダイレクトし、スマホから手入力しない場合
`tproxy-port`	`7893`	TPROXY の入口	元の宛先情報を保持したまま、ルーターで透過プロキシを使う場合

mixed-port は HTTP データを SOCKS5 に変換するものでも、別の転送層を追加するものでもありません。同じ待受ポートでクライアントのハンドシェイク形式を判別するだけです。「PCで Clash を実行し、スマホにPCのIPアドレスとポートを入力する」構成では、ポートの競合やファイアウォールルールの数を減らせます。

allow-lan で有効になること

デフォルトでループバックアドレスだけを待ち受ける場合、プロキシ入口へ接続できるのは mihomo が動作しているPC自身だけです。allow-lan: true を有効にすると、LAN内のデバイスからプロキシへ接続できるようになります。ただし、スマホの設定が自動変更されたり、PCがデフォルトゲートウェイになったりするわけではありません。クライアントでプロキシサーバーのアドレスを明示的に入力するか、ルーターや透過プロキシのルールで通信を受け渡す必要があります。

まず動作確認に使える基本設定を示します。PCの家庭内ネットワークにおける IPv4 アドレスを 192.168.50.23、スマホとPCが同じルーターに接続し、ポートに 7890 を使う想定です。

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

authentication:
  - "livingroom:change-this-password"

bind-address: "*" は利用可能なアドレスで待ち受けることを意味しますが、実際に到達できる範囲はOSのファイアウォール、ルーターのゲストネットワーク分離、アクセスポイントのクライアント分離によって制限されます。PCが固定のLANアドレスを長期的に使う場合は、次のように特定のNICに待受先を絞ることもできます。

mixed-port: 7890
allow-lan: true
bind-address: 192.168.50.23
mode: rule

authentication:
  - "phone:use-a-long-password"

特定のアドレスにバインドすると境界を明確にできますが、DHCP によってアドレスが再割り当てされると、そのアドレスが本機に属さなくなり、mihomo の起動に失敗する可能性があります。長期的に共有する場合は、ルーターの DHCP 設定でPCのNICに 192.168.50.23 を予約するか、全アドレスで待ち受けたうえでOSのファイアウォールにより接続元のネットワーク範囲を制限してください。

GUIのスイッチと YAML の関係

Clash の各GUIクライアントでは項目名が多少異なります。一般的には「設定」→「パラメーター設定」→「LAN接続を許可」と進み、同じ画面に「混合ポート」または「ポート」が表示されます。スイッチを有効にしたら、設定画面や実行ログに戻り、最終値が allow-lan: true になっていることと、実際のポート番号を確認してください。サブスクリプションを再読み込みしてもグローバル設定を保持するクライアントがある一方、上書き設定を優先するクライアントもあります。サブスクリプションファイルの項目だけを見て判断しないでください。

プロキシポートとコントロールポートも区別が必要です。external-controller: 127.0.0.1:9090 はダッシュボードやAPIの制御用であり、スマホの HTTP プロキシではありません。スマホのプロキシ欄に 9090 を入力しても、通常は接続失敗や HTTP ステータスエラーになります。

PCのLAN内アドレスを正しく確認する

スマホにはPCのLAN内アドレスを入力します。127.0.0.1 や、通信事業者から割り当てられたグローバルアドレスではありません。スマホ上の 127.0.0.1 はスマホ自身を指します。家庭内ネットワークでよく使われるアドレス範囲は 192.168.0.0/16、10.0.0.0/8、172.16.0.0/12 です。

Windows 11でアドレスを確認する

「設定」→「ネットワークとインターネット」を開きます。
現在使用中の「Wi-Fi」または「イーサネット」を選択します。
「ハードウェアのプロパティ」を開き、「IPv4 アドレス」を確認します。
192.168.50.23 のようなアドレスを記録し、デフォルトゲートウェイの 192.168.50.1 は入力しないでください。

ターミナルで ipconfig を実行し、接続中のNICに表示される「IPv4 アドレス」を確認する方法もあります。有線、無線、仮想マシン、VPNのNICが同時に存在する場合は、スマホと同じサブネットにある物理NICを選びます。スマホが 192.168.50.88 なら、PCも通常は 192.168.50.x になります。

macOSでアドレスを確認する

「システム設定」→「ネットワーク」を開きます。
状態が「接続済み」の Wi-Fi または Ethernet を選択します。
「詳細」→「TCP/IP」をクリックします。
IPv4 アドレスを確認します。例：192.168.50.23。

スマホとテレビボックスでプロキシを設定する方法

iPhone と iPad

「設定」→「Wi-Fi」を開きます。
接続中のネットワークの右側にある情報ボタンをタップします。
「HTTPプロキシ」までスクロールし、「手動」を選択します。
サーバーにPCのアドレス（例：192.168.50.23）を入力します。
ポートに 7890 を入力します。
authentication を設定している場合は認証を有効にし、対応するユーザー名とパスワードを入力します。

iOSのWi-Fi手動プロキシは主に HTTP プロキシの設定であり、システム全体の TUN とは異なります。システムプロキシに従うアプリの多くは接続できますが、独自のネットワークスタックを使うアプリ、システムプロキシを無視するアプリ、UDPのみを送信するアプリはPCを経由しないことがあります。ブラウザーは正常なのに、特定のゲームや動画配信アプリだけが直接接続するのは、このためです。

Android とテレビボックス

「設定」→「ネットワークとインターネット」→「インターネット」または現在の Wi-Fi を開きます。
ネットワークの編集を選び、「詳細設定」を展開します。
プロキシを「手動」に変更します。
プロキシのホスト名に 192.168.50.23、プロキシポートに 7890 を入力します。
必要に応じて除外リストにLAN内のドメインを入力し、保存後にアプリを再起動して確認します。

Android端末メーカーのUIによっては、「Wi-Fi」→「接続済みネットワーク」→「ネットワークを変更」に入口があります。テレビボックスに「プロキシサーバー」と「プロキシポート」しかない場合も、PCのアドレスと混合ポートを入力します。一部のテレビアプリはシステムの HTTP プロキシに従わないため、その場合はテレビボックスのWi-Fiプロキシを変更するだけでは全通信をカバーできません。

ゲーム、UDP、スマートテレビアプリ、システムプロキシを読み取らないプログラムまで一括して振り分けたい場合は、mihomo をメインルーターまたはサブルーターに配置するか、転送設定が可能な Linux ホストで TPROXY／TUN を設定します。PCでIP転送、NAT、透過プロキシルールを有効にしていない状態で、スマホのデフォルトゲートウェイだけをPCのアドレスに変更しても、利用可能な経路は自動的には形成されません。

共有後も出口を決めるのはPC側のルール

LAN内のデバイスが mixed-port に接続すると、リクエストはPC上の mihomo に入ります。サブスクリプションのノード、ポリシーグループ、DNS設定、rules は、PCで現在読み込まれている設定に従います。スマホでサブスクリプションを再インポートする必要はなく、PC側のルールモードを迂回してノードを直接選ぶこともできません。

たとえば設定が mode: rule の場合、通信はルールを上から順に照合します。ルーターの管理画面、NAS、キャスト機器へアクセスする際にプロキシノードへ送られないよう、LAN内アドレスは通常、ダイレクト接続にします。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,Proxy

Fake-IP を有効にしている場合、スマホが HTTP プロキシ経由でドメインへアクセスすると、名前解決は通常プロキシ側で処理されます。ただし、スマホ自身がプロキシを経由せずに送るDNSリクエストは、現在のWi-FiのDNSを使います。「Webページは開けるのに、アプリ内のドメイン解決だけがおかしい」場合は、すぐにサブスクリプションのノードを変更するのではなく、そのアプリが本当にシステムプロキシを使っているかを確認してください。

再現可能な手順で動作を確認する

まずPC上で 127.0.0.1:7890 を使い、対象サイトへアクセスできることを確認します。
テスト通信がモバイル回線へ迂回しないよう、スマホのモバイルデータ通信をオフにします。
スマホに 192.168.50.23:7890 を入力し、まだキャッシュされていないWebページを開きます。
Clash の接続一覧を確認し、接続元アドレスにスマホのIP（例：192.168.50.88）が表示されることを確認します。
その接続に適用されたルール、ポリシーグループ、最終ノードを確認します。

同じWi-Fi内では、スマホからPCまでのLAN往復遅延は通常 1–10 ms 程度です。50 ms を継続的に超える場合は、無線信号、2.4 GHz帯の混雑、PCのスリープ状態を確認してください。この遅延はLAN経路だけを示すもので、プロキシノードのインターネット越しの品質を表すものではありません。

認証、ファイアウォール、待受範囲

LAN内で待ち受けると、同じネットワーク上でそのポートに到達できるデバイスは接続を開始できる可能性があります。家庭内の端末が少ない場合でも、ユーザー名と推測されにくい長いパスワードを設定し、OSのファイアウォールで接続元を制限することをおすすめします。会社、学生寮、ホテルなど不特定多数が利用するネットワークでは、プロキシをネットワーク全体に公開しないでください。

mihomo の受信認証

mixed-port: 7890
allow-lan: true
bind-address: "*"

authentication:
  - "phone:V7k9m2Qp4s8L"
  - "tvbox:R6w3n8Hx5c2A"

デバイスごとに個別のアカウントを割り当てれば、特定の端末を停止するときも該当項目を削除するだけで済みます。パスワードは YAML に記載されるため、設定ファイルを本機で読み取れるユーザーを制限してください。GUIクライアントが実行用設定を自動生成する場合は、「上書き」または「グローバル拡張設定」機能でこれらの項目を管理し、サブスクリプション更新で失われないようにします。

システムのファイアウォールは家庭内ネットワークだけ許可する

Windows ファイアウォールで受信規則を作成する際は、TCPとローカルポート 7890 を選び、プロファイルは「プライベート」のみにします。リモートIPアドレスには 192.168.50.0/24 を指定してください。トラブルシューティングのためにファイアウォール全体を長時間無効化しないでください。macOSでサードパーティ製ファイアウォールや pf を使う場合も、ネットワーク範囲とポートを条件に許可します。

mixed-port で通常の HTTP と SOCKS のTCP接続を受けるには、少なくともTCPポートが必要です。SOCKS5でUDPを使う場合は、クライアント、mihomo の待受設定、OSファイアウォールのUDPルールが対応していることも確認してください。テレビボックスの HTTP プロキシは通常 SOCKS のUDPを使わないため、TCP 7890 を開放すれば、基本的なWebページとアプリの動作確認には十分です。

接続失敗を切り分ける手順

第1段階：mihomo が実際に待ち受けているか確認する

まずクライアントの実行ログとポート設定を確認します。Windowsでは netstat -ano | findstr :7890、macOSまたはLinuxでは lsof -nP -iTCP:7890 -sTCP:LISTEN を実行できます。127.0.0.1:7890 しか表示されない場合、サービスは本機に限定されています。0.0.0.0:7890、*:7890、またはPCのLANアドレスが表示されて初めて、リモート接続の条件が整います。

第2段階：ネットワーク層とファイアウォールを確認する

スマホとPCがゲストネットワークではなく、同じ通常のWi-Fiに接続されているか。
DHCPの更新によってPCのアドレスが変わっていないか。
Windowsの現在のネットワークが「パブリック」と認識され、プライベートネットワーク向けの許可ルールが適用されていない状態になっていないか。
ルーターでAP隔離、クライアント分離、異なるVLAN間の通信遮断が有効になっていないか。
別のプロセスがポートを使用しているため、Clash が実際には別のポートへ変更されていないか。

第3段階：「接続できない」と「ルールの振り分けが誤っている」を区別する

スマホに「プロキシサーバーが接続を拒否しました」とすぐ表示される場合は、通常、待受アドレス、ポート、またはファイアウォールの問題です。Clash の接続一覧にリクエストが表示されるのにWebサイトがタイムアウトする場合は、ノード、DNS、ルールの適用結果を確認します。407 Proxy Authentication Required が返る場合、プロキシには到達できていますが、ユーザー名またはパスワードが未入力か、誤っています。

特定のアプリだけが失敗する場合は、まずブラウザーを基準に確認します。ブラウザーが成功するなら、LAN経路、HTTPプロキシ、認証は基本的に正常です。失敗するアプリはシステムプロキシを使わない、QUIC／UDPを使う、独自のネットワーク設定を持つ、といった可能性があります。この場合、allow-lan を何度も切り替えても通常は結果は変わりません。

長期運用時の構成を選ぶ

一時的にスマホ1台をPCへ接続するだけなら、mixed-port: 7890、allow-lan: true、認証、LAN向けファイアウォールルールで対応できます。PCはスリープさせず、Clash クライアントを起動し続ける必要があります。PCがスリープしたり、Wi-Fiを切り替えたり、コアを終了したりすると、下流のデバイスはすぐにプロキシ接続を失います。

複数のテレビ、ゲーム機、IoT機器を安定して振り分けたい場合、PC共有は電源状態、アドレス変更、アプリのプロキシ対応状況に左右されます。その場合は、ルーターまたはサブルーターで mihomo を動かし、TUN、REDIR、TPROXY で転送を受けたうえで、送信元IP、宛先ドメイン、ルールセットに基づいて振り分ける構成が適しています。mixed-port は手動でプロキシを指定するデバイス向けに残せますが、家庭内ネットワーク全体の唯一の入口にする必要はありません。

最終確認は4項目に整理できます。プロキシポートがデバイスの入力値と一致していること、allow-lan と待受アドレスがリモート接続を許可していること、OSのファイアウォールが信頼できるネットワーク範囲だけを許可していること、ルールモードでプライベートアドレスをダイレクト接続にしていることです。ポート、DNS、TUN、サブスクリプションを一度に変更するより、4項目を個別に確認する方が原因を特定しやすくなります。