Clash Allow LAN でスマホやタブレットが繋がらない：バインド、mixed-port、Windows／macOS ファイアウォールのチェックリスト

この記事で扱う症状

ノート PC やデスクトップで Clash（Mihomo／Clash Meta 系の GUI を含む）を起動し、ダッシュボードから Allow LAN を有効にしたうえで、スマートフォンやタブレットの Wi-Fi 設定に「HTTP プロキシ：手動」と PC の LAN アドレスとポートを入れたのに、ブラウザが開かない・アプリがタイムアウトする、あるいは一瞬だけ通ってすぐ切れる——といったケースを想定しています。

原因は「購読が壊れている」より先に、到達性のレイヤー（同じ Ethernet セグメントにいるか、ポートがどこにバインドされているか、OS が外部からの TCP を落としていないか）に偏ることが多いです。本稿では現場で手戻りが少ない順番でチェック項目を並べます。クライアントごとのメニュー名は異なりますが、考え方は共通です。

切り分けの全体像

おおまかには、（1）端末同士が本当に同じ L2／L3 ネットワークにいるか（2）プロキシが 127.0.0.1 だけでなく LAN 側に開いているか（3）HTTP と SOCKS でポート番号を取り違えていないか（4）OS やルーターが受信をブロックしていないか、の四層です。上から順に潰すと、設定ファイルの細部に入る前に半分以上は解決します。

  1. スマホと PC が同一 SSID／同一サブネットか（ゲスト Wi-Fi や VPN オンデマンドで分離されていないか）。
  2. PC の IPv4 アドレスを再確認し、他端末から ping や管理画面の接続テストが可能なら実行する。
  3. Allow LAN と bind-address／外部アクセス許可の組み合わせを確認する。
  4. mixed-port と個別の port／socks-port のどちらをスマホに書くべきか整理する。
  5. Windows なら Defender ファイアウォールの受信規則、macOS ならファイアウォールとローカルネットワーク権限を確認する。
  6. 最後にルーターの AP 隔離・クライアント隔離・メッシュ子機のブリッジ不整合を疑う。

用語：本稿では「LAN 共有プロキシ」と、同一宅内 Wi-Fi から PC 上の Clash が提供する HTTP／SOCKS エンドポイントへの接続を指します。Allow LAN は多くの実装で「ループバック以外からの接続を受け付ける」ためのスイッチですが、実際には YAML の bind-address や external-controller 周りとセットで効きます。

ステップ 1：本当に「同じ LAN」か

まずスマホの Wi-Fi 詳細で割り当てられた IPv4 を見て、PC のアドレスとネットマスクが噛み合うかを確認してください。例えば PC が 192.168.1.10/24 なのにスマホが 192.168.4.x なら、ゲスト VLAN か別ルーターに乗っている可能性が高いです。キャリアの「おサイフケータイ用」VPN や iCloud プライベートリレー、Android の「常時オン VPN」が有効だと、DNS や経路が意図せず分岐し、プロキシ設定だけでは説明がつかない挙動になります。

社宅やシェアハウスでは、見た目同じ SSID でもポート隔離が有効なことがあります。管理画面で AP 隔離／クライアント隔離がオンなら、端末同士が互いに TCP を張れないため、Clash が正しく動いていてもスマホから PC のポートへ届きません。ここはアプリ設定では直せないので、ルーター側の変更か別 SSID の利用が必要です。

ステップ 2：Allow LAN とバインド先

Allow LAN をオンにしても、設定ファイル側で bind-address: 127.0.0.1 のままだと、GUI のトグルと実際のリスンが食い違う例があります。期待どおり LAN から受けたい場合は 0.0.0.0 もしくは実装が許す「すべてのインターフェース」相当へ揃えるのが安全です。変更後はコアの再起動が必要なクライアントが多いので、反映忘れに注意してください。

外部コントローラ（ダッシュボード）用ポートを開けっぱなしにしているとセキュリティ上の議論になりますが、本稿の焦点はスマホからの通常プロキシ接続です。管理 UI 用ポートと HTTP プロキシ用ポートを混同しないことも重要です。代表的な GUI の導線や権限まわりは、Clash Verge Rev の日本語チュートリアルで Windows／macOS 別に触れています。まずはそちらで「システムプロキシ」「サービスモード」「TUN 権限」の関係を押さえたうえで、本稿の LAN 到達性チェックに進むと理解が早いです。

ステップ 3：mixed-port とプロキシ種別

Clash 系では mixed-port が有効な場合、同一 TCP ポート上で HTTP CONNECT と SOCKS5 の両方を扱えることがあります。一方、古い構成や一部クライアントでは port（HTTP）と socks-port（SOCKS5）が分かれているため、スマホ側の「プロキシの種類」と番号が1 つでもずれると即不通になります。iOS の「手動」設定は HTTP ベースであることが多く、SOCKS 専用ポートを入れると失敗します。Android もアプリによっては SOCKS のみ対応です。

切り分けとしては、PC のブラウザでいったん 127.0.0.1:mixed-port に接続できるかを確認し、同じ番号を LAN IP に置き換えてスマホから試すのが素直です。別途 TUN モードで全トラフィックを吸い上げている場合、システムプロキシと LAN 共有の期待値がずれやすいので、TUN モードのガイドで挙動の違いを押さえておくと混乱が減ります。

ステップ 4：Windows Defender ファイアウォール

Windows 10／11 では、初回に実行ファイルがネットワークを使用しようとしたときのダイアログで「パブリック」を選んでしまうと、後から LAN 共有を有効化しても受信がブロックされたままになることがあります。コントロールパネルまたは設定アプリから「Windows セキュリティ」→「ファイアウォールとネットワーク保護」→「詳細設定」を開き、対象実行ファイル（例：GUI 本体や埋め込みコア）に対する受信規則で TCP の該当ポートが許可されているかを確認してください。

社用端末ではグループポリシーでインバウンドが一律禁止されているケースもあります。その場合はユーザー権限では解決できず、IT 管理者への申請が必要です。切り分けのため一時的にファイアウォールをオフにするのはセキュリティリスクが高いので、特定プロファイルに限定した許可規則を作る方が望ましいです。ルールを追加したら必ず「プライベート」ネットワークに接続しているかも併せて確認します。

ステップ 5：macOS のファイアウォールとローカルネットワーク

macOS ではシステム設定の「ネットワーク」→「ファイアウォール」から、ブロックされているアプリがないかを見ます。さらに近年の OS では、Sandbox されたアプリが同一 LAN のデバイスを探索する際に「ローカルネットワーク」の許可ダイアログが出ます。GUI ランチャー経由でコアを動かしている構成では、この許可がオフのままだと期待どおりにリッスンできないことがあるため、設定アプリの「プライバシーとセキュリティ」→「ローカルネットワーク」も確認してください。

Little Snitch や Lulu などのサードパーティフィルタを入れている場合は、インバウンドの拒否ルールが優先される点に注意が必要です。VPN クライアントが utun インターフェースを占有しているときも、ルーティングテーブルが変わり LAN 側への戻り経路が分かりにくくなるので、VPN を一時停止して再現するかどうかを見る価値があります。

ステップ 6：ルーター・メッシュ・IPv6

中級者向けの落とし穴として、IPv6 が有効な環境で名前解決だけ v6 に流れ、プロキシ経路と整合しない例があります。切り分けのため一時的にスマホ側で IPv6 をオフにして挙動が変わるかを見るのも手です。メッシュ Wi-Fi の子機にだけクライアント隔離オプションがある製品もあるため、親機直下と子機直下で挙動が変わるか比較すると原因が絞れます。

また、PC が有線、スマホが無線でも同一 L3 であれば本来は到達しますが、セグメントが分断されているとダメです。ホテルや公共 Wi-Fi ではそもそもクライアント間通信が禁止されていることが多いので、自宅ラボと同じ手順が通らないのは正常です。

すぐ試せる確認コマンド（PC 側）

PC 自身からポートが開いているかを確認するには、別ターミナルで curl -x http://127.0.0.1:PORT http://cp.cloudflare.com/ のように疎通を取る方法があります。LAN からの確認は、可能なら第三の端末から nc -vz PC_IP PORT 相当の TCP 接続テストを行うと、ファイアウォールで落ちているのかルーティングの問題なのかが分かれます。Windows なら PowerShell の Test-NetConnection でも代替できます。

運用メモ：LAN 共有は便利ですが、信頼できない端末が同じネットワークにいる場合は、プロキシ越しに社内イントラや管理画面へ到達できてしまうリスクがあります。不要なときは Allow LAN をオフに戻す、またはルーターでデバイス単位の VLAN を分けるなど、ネットワーク設計とセットで考えるのが安全です。

ドキュメントと入手先

ルールや DNS の詳細は、当サイトのドキュメント集も参照してください。クライアントのバイナリは配布元が分岐しやすいので、説明が一貫している導線としてダウンロードページを主な入手先にすると取り違えが減ります。

まとめ

Clash Allow LAN をオンにしてもスマホから繋がらないときは、まず同一サブネットと AP 隔離を確認し、次に Listen 先とポート種別（mixed-port と HTTP／SOCKS の対応）を揃え、最後に Windows や macOS の受信を許可する、という順が効率的です。アプリ設定だけをいじっても、OS やルーターが最初の SYN を捨てているケースでは改善しません。

同種の用途でも、Clash／Mihomo はポートとルール表現が明快で、GUI と YAML の両方から状態を追いやすいのが長所です。LAN 共有は一時的な検証に便利ですが、長期運用では端末ごとにクライアントを入れるほうがポリシー管理しやすい場面もあります。

各 OS 向けの推奨クライアントはダウンロードページにまとめています。PC 側の到達性を一度通しで点検したうえで、必要ならスマホ用のビルドも併せて導入すると、体験のばらつきを抑えやすくなります。→ Clash クライアントを無料でダウンロードし、マルチデバイス環境を整える