Clash で LAN プロキシ共有：mixed-port・allow-lan と多機器接続
すでにPC 上で Clash（Meta / Mihomo 系）を動かし、購読とルールで自分のブラウザまでは通っている——そこから一歩進めて、同じ Wi‑Fi（同一 L2 セグメント）にあるスマートフォン・タブレット・別の PCも、ゲートウェイ機の Clash 経由で出口を共有したい、というニーズはとても多いです。本記事では mixed-port で HTTP と SOCKS を同一ポートにまとめる考え方、allow-lan でLAN からの接続を許可する設定、ゲートウェイ側の LAN IP とポート番号の確認、クライアント側へのプロキシの入れ方、そしてつながらないときの切り分け（OS ファイアウォール、別サブネット、誤った IP など）を、2026 年時点の一般的な Clash 系クライアントに沿って整理します。
なぜ mixed-port と allow-lan がセットで語られるか
スマホや他 PC に個別に VPN アプリやフル設定の Clashを入れず、家やオフィスの一台の PCだけを「出口の司令塔」にしたい場合、ゲートウェイ PC はプロキシサーバとして振る舞う必要があります。そのときクライアント側アプリは、多くの場合 HTTP プロキシか SOCKS5のどちらか（または両方）を要求します。従来の Clash 設定では port（HTTP）と socks-port（SOCKS）を別々に持てましたが、mixed-portを使うと一つのポート番号に両プロトコルを束ねられ、ルータのポート開放やメモ用の数字がシンプルになります。
一方、デフォルトでは Clash はループバック（127.0.0.1）向けにだけリッスンし、同一 LAN 上の別端末から届く接続は受け付けません。そこで allow-lan: true が必要です。これを有効にすると、適切な bind-address（後述）と組み合わせて、イーサネット／Wi‑Fi インターフェースに割り当てられた IPv4 アドレス宛のトラフィックを受け入れられるようになります。つまり検索で「Clash 局域网」「LAN プロキシ」と一緒に出てくる二語は、「一つのポートで HTTP/SOCKS を扱う」と「LAN から繋いでよい」という、別レイヤーの要件をそれぞれ表しています。
前提と安全上の注意
対象は自分が管理するネットワーク上の機器に限ります。職場・学校・公共の Wi‑Fiで他人にプロキシを配らないでください。allow-lan をオンにすると、同一 LAN にいる機器からゲートウェイ PC のプロキシポートに届く可能性があります。信頼できない端末が混ざる環境では、OS のファイアウォールで送信元 IP を制限する、ゲスト SSID とは切り離す、などネットワーク設計とセットで考える必要があります。外部コントローラや API については別の論点ですが、本記事の焦点はLAN 内の HTTP/SOCKS プロキシ共有です。
LAN 共有は「閉じた信頼ネット」向け
使わないときは allow-lan を戻す、または Clash を終了する。カフェ等のオープン Wi‑Fiでは推奨しません。
設定ファイルの核：mixed-port・allow-lan・bind-address
コアの設定（YAML）のトップレベルに、概ね次のようなキーを置きます。数値は例で、実際のクライアントや購読テンプレートに合わせてください。
# Core keys — adjust port and profile to your client
mixed-port: 7890
allow-lan: true
bind-address: '*'
mixed-portを指定すると、その番号で HTTP プロキシと SOCKS5 の両方を扱えるのが一般的です（実装の詳細はコアのバージョンに依存しますが、多くの GUI はこの一本で端末設定を済ませられます）。allow-lan: trueが無いと、どれだけ IP を正しく入れても接続拒否になりがちです。
bind-addressは「どのローカルアドレスにバインドするか」です。'*' や 0.0.0.0（環境によっては非推奨表記の扱い）で全インターフェースに付ける例がよく使われます。逆に 127.0.0.1 のみだと LAN 共有になりません。VPN や仮想アダプタが多い PCでは、意図しないインターフェースにまでリッスンが広がることがあるため、トラブル時はクライアントのログで実際のバインド先を確認してください。
GUI から触る場合
Clash Verge Rev や各種 for Windows 系では「Allow LAN」「Mixed Port」「バインド」に相当するトグルや入力欄があります。YAML を直接編集しなくても同じ結果にできることが多いです。macOS の初回権限は別記事を参照してください。
ゲートウェイ PC の LAN IP を確認する
スマホの Wi‑Fi 設定に入れるサーバ名には、ループバックではなくゲートウェイ PC のプライベート IPを使います。例として IPv4 では 192.168.1.23 や 10.0.0.5 のようなアドレスです。iPhone の「個人向けホットスポット」やAndroid のテザリングでは、PC とスマホの役割が逆になるので、「プロキシを提供する側」の IPを取り違えないでください。
Windows なら ipconfig、macOS ならシステム設定または ifconfig / networksetup、Linux なら ip a 等で確認できます。有線と無線の二つに IP がある場合、スマホが接続している方（多くは同じ SSID の Wi‑Fi）と同じサブネットの IPv4 を選びます。IPv6 のみが表示される環境では、IPv4 プロキシの到達性が別問題になるため、まず IPv4 で試すのが無難です。
クライアント側：アドレスとポートの入れ方
スマートフォンでは、Wi‑Fi ネットワークの詳細からHTTP プロキシを手動にし、サーバ＝ゲートウェイ PC の LAN IP、ポート＝ mixed-port に書いた番号（例：7890）を入力します。認証が不要な通常の Clash 共有なら、ユーザー名・パスワードは空のままです。HTTPS 通信は HTTP プロキシ経由でCONNECTされるため、ブラウザやアプリによっては別途「プロキシ対応」の説明が必要な場合があります。
別の PC では、OS のシステムプロキシ設定、またはブラウザ拡張、ターミナルの環境変数 HTTP_PROXY / HTTPS_PROXY / ALL_PROXY（SOCKS の場合は socks5://IP:ポート）で指定します。SOCKS5 を選ぶ場合もホストとポートは同じ（mixed-port 利用時）で構いません。CLI ツールがプロキシを読まない場合は、ゲートウェイ側で TUN を検討しますが、それはLAN 共有とは別の話です。
| 項目 | 入れる値の例 |
|---|---|
| プロキシホスト | 192.168.x.x（ゲートウェイ PC の IPv4） |
| ポート | 7890 など mixed-port と一致 |
| 種別 | HTTP または SOCKS5（アプリの指定に合わせる） |
OS ファイアウォールと「見えているが通らない」
allow-lan と IP が正しくても、Windows Defender ファイアウォールやmacOS のファイアウォールが Clash の実行ファイルや該当ポートの着信をブロックしていると、スマホからはタイムアウトします。初回接続時に OS がダイアログを出した場合はプライベートネットワーク向けに許可を選ぶ、またはルールでTCP の対象ポート（例：7890）を明示的に開けます。セキュリティソフトの「ネットワーク隔離」機能も同様に疑ってください。
逆にping が通るのにプロキシだけ通らないケースは、ICMP は許可されているが TCP が閉じているときに起きがちです。切り分けには、ゲートウェイ PC 上で Clash のログを見ながら、スマホからブラウザでテストページを開く、同じ LAN 内の第三の機器から nc -vz IP ポート のようにポート疎通を見る、といった手順が有効です。
別サブネット・ゲスト Wi‑Fi・隔離 SSID
最近のルータはゲスト用 Wi‑Fiでクライアント同士を相互に見えなくする（AP 隔離）設定がデフォルトのことがあります。この場合、スマホからゲートウェイ PC の IP へそもそも届きません。メイン LAN の SSIDに PC もスマホも乗せる、またはルータ設定で隔離をオフにする必要があります。企業ネットワークでは VLAN で端末が分離されていることもあるため、同一セグメントかどうかを管理者に確認してください。
DNS と「繋がったように見える／見えない」
プロキシは通っているのに名前解決だけ別経路、という話は LAN 共有でも起こり得ます。ゲートウェイ側の Clash で fake-ip や redir-host を使っている場合、クライアント OS の DNS 設定と組み合わせで挙動が変わります。ブラウザだけ異常なときは、DNS・fake-ip の記事の切り分けも参照してください。まずはゲートウェイ PC 単体で同じプロファイルが安定しているかを確認してから、LAN 共有の問題に絞ると早いです。
よくある症状と確認順
スマホからタイムアウトする
allow-lan が false のまま、bind がループバックのみ、ファイアウォールが Clash をブロック、IP アドレスを誤記、ポートが購読で上書きされている、の順に疑うとよいです。購読を再取得するとトップレベルの mixed-port が変わるテンプレートもあるため、実際に動いている設定を GUI または生成 YAML で確認してください。
ブラウザだけ通らない
システムプロキシを有効にしていない、別ブラウザがプロキシ無視、iOS の「ローカルネット」関連の制限——などを確認します。
遅い・不安定
LAN 共有そのものより、ゲートウェイ PC が選択しているノードやルールの影響が大きいです。ゲートウェイ側で速度とログを先に整えます。
Windows / macOS での入口となる記事
Clash 本体の導入と購読がまだなら、先にゲートウェイ PC のセットアップを完了させてください。Windows 向けの手順は「Clash for Windows 完全設定ガイド」、macOS は「Clash Verge Rev の初回設定」が入口になります。そのうえで本記事の mixed-port / allow-lan を足すイメージです。
チェックリスト
- ゲートウェイ PC で Clash が単体で期待どおり動く。
mixed-portの番号を決め、allow-lan: trueと適切なbind-addressを設定。- LAN IP（IPv4）を控え、クライアントのプロキシに「IP:ポート」を入力。
- OS ファイアウォールで該当ポートの着信を許可。
- 同一サブネット・非隔離 SSID であることを確認。
まとめ
mixed-portでクライアント設定を単純化し、allow-lanで LAN からのアクセスを許可し、正しい LAN IP とポートを各端末に配る——この三点が揃えば、同一 Wi‑Fi 上の多機器をゲートウェイ PC の Clash に乗せる構成が実現しやすくなります。詰まったらファイアウォールとサブネット隔離を疑い、ゲートウェイ側のログで接続が届いているかを見てください。