2026-11-05 応用設定読了時間：約10分

ClashのLAN共有プロキシ設定｜mixed-port・allow-lanの使い方

mixed-portとallow-lanの役割を解説。スマホやテレビ、ゲーム機から同じLAN上のPC経由でプロキシを使う設定手順と、ファイアウォールの注意点を紹介します。

プロキシ共有の接続経路と利用条件

LAN共有プロキシとは、ClashまたはClash Meta（mihomo）コアがPC上で待ち受けるプロキシポートに、ほかの端末から接続する方法です。通信経路は「スマホやテレビ → PCのLAN内アドレスとポート → コアのルール → 該当するアウトバウンド」です。PCの電源を入れたままにし、クライアントのコアを動作させる必要があります。PCがスリープすると、この経路は切断されます。

ここでは、PCのIPv4アドレスを192.168.1.20、混合ポートを7890、ホームネットワークの範囲を192.168.1.0/24とする例を使います。これらは設定例であり、お使いのネットワークを調査した結果ではありません。実際に設定する際は、PCの現在のネットワークアダプターに割り当てられているアドレスに置き換えてください。

対象：端末やアプリがHTTPプロキシまたはSOCKS5プロキシの手動設定に対応している場合。
前提条件：端末からPCのLAN内アドレスに直接アクセスでき、PCのファイアウォールで該当する受信接続が許可されていること。
注意点：Wi-FiのHTTPプロキシ設定は通常すべてのアプリには適用されず、端末全体の透過プロキシと同じものではありません。
違い：待ち受けポートを共有するだけなら、PCをデフォルトゲートウェイに設定する必要も、TUNモードを有効にする必要もありません。

mixed-port・allow-lan・bind-addressの役割

この3つの項目はそれぞれ、待ち受けるプロトコル、LAN内からの接続を許可するか、どのローカルアドレスにバインドするかを指定します。いずれも設定のトップレベルに置き、proxies、proxy-groups、rulesと同じ階層に記述します。個々のプロキシノードの下にインデントしないでください。

項目	設定例	役割
`mixed-port`	`7890`	1つのポートでHTTPとSOCKSのプロキシリクエストを受け付けます。
`allow-lan`	`true`	LAN内の端末からのプロキシ接続をコアで受け付けます。
`bind-address`	`"*"`	すべてのアドレスにバインドします。実際にアクセスできる接続元はファイアウォールで制限してください。
`port`	`7891`	HTTPプロキシ専用の入口です。混合ポートを使うために必須ではありません。
`socks-port`	`7892`	SOCKSプロキシ専用の入口です。必要に応じて設定します。

共有に必要な最小限の設定

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

次の設定は既存の設定に追加する項目であり、サブスクリプション設定全体ではありません。既存のノード、プロキシグループ、DNS、ルールはそのまま残してください。トップレベルにmixed-portがすでにある場合は、その値を変更します。同じ項目を重複して追加しないでください。また、portなど別の待ち受けサービスが7890を使用していないことも確認してください。

"*"の引用符は必ず残してください。引用符がないと、YAMLでアスタリスクがエイリアス構文として解釈されることがあります。特定のネットワークアダプターだけで待ち受ける場合は、bind-addressを192.168.1.20に変更できます。この方法はアドレスが変わらないことが前提です。PCのネットワークを切り替えたり、DHCPでアドレスが変わったりすると待ち受けに失敗するため、設定も更新してください。

external-controllerはコントロール用インターフェースであり、端末が接続するプロキシの入口ではありません。スマホのプロキシポートには、mixed-portで指定した7890を入力してください。コントロール用インターフェースのポートを入力してはいけません。プロキシ共有のためにコントロール用インターフェースをLANに公開する必要はありません。

PC側の設定：アドレス確認・設定適用・待ち受け確認

1. 使用中のLAN内IPv4アドレスを確認する

Windowsでは「設定」→「ネットワークとインターネット」→「Wi-Fi」→接続中のネットワークのプロパティを開き、IPv4アドレスを確認します。有線接続の場合は「イーサネット」を開いてください。ターミナルでipconfigを実行し、現在接続中のアダプターのIPv4アドレスとサブネットマスクを確認する方法もあります。

macOSでは「システム設定」→「ネットワーク」→接続中のネットワーク→「詳細」→「TCP/IP」を開きます。ループバックアドレスの127.0.0.1、仮想ネットワークアダプターのアドレス、切断済みアダプターのアドレスは使わないでください。他の端末で127.0.0.1を指定すると、その端末自身を指します。このPCを指すわけではありません。

2. 実際に適用される設定を変更する

クライアントで現在有効な設定を確認し、既存のポートとLANアクセスの設定を控えます。
クライアントが対応する設定編集、オーバーライド、またはマージ機能を使い、上記3つのトップレベル項目を追加します。
保存後、設定を再読み込みします。クライアントからコアの再起動を求められた場合は、案内に従ってください。
実行ログを確認し、YAMLの解析エラーやポートの競合がないことを確認します。

設定項目の名称やオーバーライドの優先順位はクライアントによって異なります。画面上の「LANからの接続を許可」は通常allow-lanに対応しますが、サブスクリプションから生成されたファイルを直接編集すると、更新時に変更が上書きされる場合があります。クライアントが提供する永続的なオーバーライド機能を優先して使い、編集画面に表示される元のサブスクリプションだけでなく、最終的に適用される設定を確認してください。

3. 到達可能なアドレスで待ち受けているか確認する

Windows PowerShellでは次のコマンドでTCPの待ち受けアドレスを確認できます。macOSでは2つ目のコマンドを使えます。

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

127.0.0.1:7890しか表示されない場合、ほかの端末からPCのLAN内IPv4アドレス経由で接続することはできません。すべてのIPv4アドレスで待ち受けている場合、一般的な表示は0.0.0.0:7890です。特定のアドレスにバインドしている場合は、該当する192.168.1.20:7890が表示されます。IPv6のワイルドカード待ち受けが表示される場合は、システムのデュアルスタックの動作と別端末からの接続テストも確認してください。待ち受けの表示だけでIPv4の到達性を判断することはできません。

ファイアウォールとWi-Fiの端末間通信制限を確認

allow-lan: trueにしても、OSのファイアウォールが自動で通信を許可するわけではありません。ポートは待ち受けているのに別端末から接続がタイムアウトする場合は、ネットワークプロファイル、受信規則、Wi-Fiの端末間通信制限を優先して確認してください。最初にプロキシノードを変更する必要はありません。

Windows：プライベートネットワークでTCP 7890のみを許可

信頼できる家庭内ネットワークでは、まず現在の接続がWindowsで「プライベートネットワーク」と認識されていることを確認します。「Windows セキュリティ」→「ファイアウォールとネットワーク保護」→「詳細設定」を開き、「受信の規則」で新しいポート規則を作成します。TCP、特定のローカルポート7890、接続を許可する設定を選び、「プライベート」のみをチェックします。規則の「プロパティ」→「スコープ」で、リモートIPの範囲を実際のホームネットワークに限定してください。

管理者として起動したPowerShellから、接続元を限定した規則を作成する方法もあります。次の例では、192.168.1.0/24からPCの192.168.1.20にあるTCP 7890への接続のみを許可します。実行前に、実際のネットワークに合わせてアドレスを変更してください。

New-NetFirewallRule -DisplayName "Clash LAN TCP 7890" `
  -Direction Inbound -Action Allow -Protocol TCP `
  -LocalAddress 192.168.1.20 -LocalPort 7890 `
  -RemoteAddress 192.168.1.0/24 -Profile Private

この規則は、この記事で行うHTTPプロキシ接続テスト用です。SOCKS5のUDP転送が設定済みであることを示すものではありません。既存の広範な許可規則がある場合は、あわせて確認してください。制限付きの規則を追加しても、ほかの許可規則が自動で制限されるわけではありません。接続問題を長期的に解決するために、ファイアウォール全体を無効にしないでください。

macOSとルーター側の確認

macOSでは「システム設定」→「ネットワーク」→「ファイアウォール」→「オプション」で、該当クライアントまたは実際に動作しているコアの受信接続権限を確認します。「すべての着信接続をブロック」が有効だと、共有できない場合があります。
スマホとPCが同じ名前のWi-Fiに接続していても、ゲストネットワークや別のVLANに接続されていたり、APの端末間通信制限によって遮断されていたりする場合があります。
PCを有線、スマホをWi-Fiで接続していても、必ずしも問題になるわけではありません。重要なのは、ルーターが両者間の通信を許可しているかどうかです。
ルーターでインターネット向けのポート転送を設定する必要はありません。プロキシポートをDMZに追加しないでください。

スマホ・テレビ・ゲーム機に入力する設定

iPhone・iPad：接続中のWi-FiにHTTPプロキシを設定

「設定」→「Wi-Fi」を開き、接続中のネットワークの横にある情報ボタンをタップします。
「プロキシを構成」を開き、「手動」を選択します。
サーバーに192.168.1.20、ポートに7890を入力します。
この記事の基本設定にはプロキシ認証を設定していないため、認証はオフのまま保存し、ブラウザーで接続をテストします。

サーバー欄にはIPアドレスだけを入力し、http://やポート番号は含めないでください。この設定が適用されるのは現在のWi-Fiです。モバイルデータ通信に切り替えると、このLAN内アドレスは使われません。

Android：接続中のネットワークで手動プロキシを選択

一般的な設定場所は「設定」→「ネットワークとインターネット」→「インターネット」→接続中のWi-Fi→「編集」→「詳細設定」→「プロキシ」→「手動」です。メーカーによって項目名は異なる場合があります。プロキシのホスト名に192.168.1.20、ポートに7890を入力します。テスト中は、テスト対象のドメインが除外されないよう、複雑なバイパスアドレスリストを追加しないでください。

AndroidのWi-Fiプロキシも、アプリがシステムのプロキシ設定に従うことが前提です。ブラウザーでは接続できるのに特定のアプリで通信できない場合でも、すぐにポート設定の誤りと判断しないでください。アプリがHTTPプロキシに対応しているか、独自のネットワーク設定を備えているかを確認します。

テレビ・ゲーム機：対応しているプロキシ方式を確認

ネットワーク設定に「HTTPプロキシサーバー」がある場合は、同じアドレスとポートを入力します。SOCKS5しか選べない場合でも、混合ポートは対応するプロキシリクエストを受け付けますが、アプリ側がSOCKS5に正しく対応している必要があります。手動プロキシの設定項目がない端末は、DNSを変更してもHTTPプロキシを使えるようにはなりません。

ゲーム機にHTTPプロキシを設定すると、ストアの表示、ダウンロード、ログイン時の動作が変わることがあります。一方、オンラインゲームの通信がそのポートを経由するとは限りません。特にUDP通信については、Webページが一度表示できたからといって、オンラインゲームの通信もすべてプロキシ経由になったとは判断できません。PCでIP転送、ルーティング、透過プロキシを別途設定していない限り、PCのアドレスをデフォルトゲートウェイに指定しないでください。

段階的に検証：ポート・プロキシリクエスト・ルールのアウトバウンド

まず接続が待ち受けポートに到達することを確認し、その後、接続先サイトとルールを調べます。次のコマンドは、別のLAN内PCから実行してください。プロキシを動かしているPC上でテストしても、ローカルの接続経路しか検証できず、ファイアウォールやWi-Fiの端末間通信制限を十分に確認できません。

# Windows PowerShell：接続先のTCPポートを確認
Test-NetConnection 192.168.1.20 -Port 7890

# Windowsではcurl.exeを使用。macOSまたはLinuxではcurlを使用
curl.exe -I --connect-timeout 5 --max-time 15 \
  --proxy http://192.168.1.20:7890 https://example.com/

上記のバックスラッシュによる行継続は、一般的なUnixシェル向けです。WindowsではPowerShellの行継続構文の違いを避けるため、curlコマンドを次のように1行で実行できます。

curl.exe -I --connect-timeout 5 --max-time 15 --proxy http://192.168.1.20:7890 https://example.com/

https://example.com/は接続確認用のテスト先であり、プロキシの出口を専用に検証するサービスではありません。200 Connection establishedはHTTP CONNECTトンネルが確立したことを示すだけです。続けてTLS接続と接続先からの応答も確認してください。また、クライアントの接続一覧で送信元IP、適用されたルール、アウトバウンドの経路を確認し、このリクエストがDIRECTなのか、プロキシポリシーを経由しているのかを調べます。

症状	まず確認する項目	次に行うこと
接続が拒否される	コアが動作していない、ポートの入力ミス、ループバックアドレスのみで待ち受けている、またはファイアウォールが接続を拒否している	最終的に適用される設定とTCPの待ち受け状態を確認します。
接続がタイムアウトする	ファイアウォールによる破棄、ゲストネットワークの隔離、PCのアドレス変更	双方のネットワーク範囲と受信規則を確認します。
HTTP 407が返る	実行中の設定でプロキシ認証が要求されている	認証設定と端末の対応状況を確認します。ノードを繰り返し変更する必要はありません。
ポートには接続できるがサイトが表示されない	ルール、ノード、接続先ドメインの名前解決、または上流への接続	該当リクエストのログと実際のアウトバウンドを確認します。
ブラウザーは使えるがゲームでは通信できない	アプリがプロキシを迂回している、または対象外のUDP通信を使っている	通信方式と端末のプロキシ対応状況を確認します。

SOCKS5を確認するには、curl --proxy socks5h://192.168.1.20:7890 https://example.com/を実行します。socks5hではドメイン名の解決をプロキシ側に依頼します。一方、socks5では通常curl側で名前解決します。結果が異なることはありますが、それだけで混合ポートに問題があるとは限りません。

ルール・DNS・TUNと日常のメンテナンス

共有先の端末にもPC側のルールが適用される

mode: ruleの場合、混合ポートに入ったリクエストはrulesの順に照合され、PC側のプロキシグループで現在選択されているアウトバウンドを使います。LAN共有を有効にしても、スマホ専用のルールが自動で作られるわけではなく、すべてのサイトがリモートノードを経由するわけでもありません。出口を確認するには、クライアントに「接続済み」と表示されているかだけでなく、該当リクエストの照合結果を確認してください。

プロキシの入口とDNSサービスの入口は別

スマホにHTTPプロキシを設定しても、DNSアドレスを機械的にPCのIPアドレスへ変更する必要はありません。mixed-portはDNSの待ち受けポートではありません。内蔵DNSを有効にするか、どのアドレスで待ち受けるかは、dns.enableやdns.listenなどの設定で制御します。LAN内にDNSサービスを提供するかどうかは独立した設計判断であり、UDP/TCPのポートとファイアウォールも別途検討する必要があります。

HTTPSリクエストでHTTP CONNECTを使ってドメイン名を転送する場合、通常はプロキシ側がその後の名前解決に関与します。ただし、アプリが独自にDNSを問い合わせたり、直接接続したり、別のネットワークスタックを使ったりすることもあります。したがって、手動のHTTPプロキシを設定しただけでは、すべてのDNS通信がコアを経由しているとは限りません。

共有ポートを使うだけならTUNは不要

TUNは仮想ネットワークアダプターに入る通信を取り込む機能で、主にPC本体の透過プロキシに使われます。スマホからPCの7890に接続するだけなら、TUNを追加で有効にする必要はありません。PCでTUNを有効にしていても、同じWi-Fiに接続したすべての端末の通信が自動で取り込まれるわけではありません。それらの端末の通信を対応するゲートウェイへ転送するルーティングが別途必要です。

アドレスを固定し、元に戻す手順も用意する

ルーターでPCのDHCPアドレス予約を設定すると、再起動後にスマホのプロキシ設定で使うアドレスが変わるのを防ぎやすくなります。
サブスクリプションを更新した後は、永続的なオーバーライドが引き続き適用されているか確認してください。特にallow-lan、待ち受けアドレス、ポートを確認します。
長期間使用する場合は、クライアントが対応するauthenticationの認証設定を確認してください。テレビなどの端末は認証に対応していないことがあるため、事前に互換性を確認します。
共有を終了するときは、端末のWi-Fiプロキシを「オフ」または「なし」に戻し、PCのallow-lanをfalseに設定して再読み込みします。
不要になったファイアウォールの受信規則を削除します。そうすることで、後から別のプロセスが同じポートを使った場合に、LANからアクセスできる状態が残るのを防げます。

共有が完了したと判断できるのは、別端末から指定ポートに接続でき、実際のリクエストがコアの接続一覧に表示され、想定したルールに一致し、利用したいアプリがそのプロキシ方式に対応している場合です。この4点を個別に確認するほうが、DNS、TUN、ゲートウェイ、ノードを同時に変更するより問題を特定しやすくなります。