「LAN 許可」だけでは足りない典型パターン

多くの Clash 系クライアントには「ローカルネットワークへの接続を許可」「Allow LAN」といったチェックがあります。これは アプリが LAN 側からの着信を受け入れる意図 を表す UI ですが、実際に届くかどうかは別問題です。コアが 127.0.0.1（ループバック）だけで待ち受けていると、チェックを入れてもスマホからは到達しません。また OS のファイアウォールがプロセス単位で着信 TCP を拒否していると、同じく届きません。さらに、PC とスマホが 別サブネット にいる、ゲスト Wi‑Fi の クライアント隔離 が有効、といったネットワーク設計の問題では、プロキシ設定以前に L2/L3 で遮断されます。

つまり切り分けの順序は「UI のチェック → どのアドレスで listen しているか → FW が穴を開けているか → 端末が同じ論理ネットワークにいるか → スマホ側のプロキシ入力」が筋が良いです。ノードや TLS の話に飛ぶ前に、まず「LAN にプロキシを公開する」層を潰してください。ログの読み方は 接続ログの解説 と併用すると、外向き通信の問題とローカル到達の問題を混同しにくくなります。

ℹ 目安：スマホのブラウザでページが開かないのに、PC 単体では問題ないときは、まず「スマホ → PC のプロキシポート」が TCP で張れるかを疑います。外向きのノードは生きていても、LAN 共有が詰まっているだけ、というケースは珍しくありません。

PC の LAN IP と待ち受けポートを確定する

スマホに入力するのは PC のループバックではなく、LAN インターフェースに付いたアドレス です。Wi‑Fi に繋がっているならそのアダプタの IPv4（例：192.168.x.x）をメモします。有線と無線の両方が有効なとき、誤って別セグメント側の IP を書くと届きません。VPN や仮想アダプタが増えている環境では、実際にスマホと同じブロードキャストドメインにいるインターフェースを選ぶ必要があります。

ポート番号は config.yaml の mixed-port、または分離している場合は port（HTTP）と socks-port を確認します。external-controller のポートは管理 API 用で、ブラウザの HTTP プロキシとして使う対象ではありません。GUI クライアントによっては表示名が短縮されているので、実ファイルを開いて数値を合わせるのが確実です。製品ごとの画面差は クライアントの選び方 も参照してください。

同一 LAN 内の別マシン（可能なら）から telnet や nc で PCのIP:ポート へ接続試験すると、「届いていない」のか「届いているがプロキシ応答がおかしい」のかが分かれます。ここで既に拒否されるなら、次のバインドと FW を見ます。

設定ファイル側：allow-lan と bind-address

Mihomo／Clash Meta 系では、LAN 共有に相当する典型は allow-lan: true と、待ち受けをすべてのインターフェースに広げる bind-address: '*' もしくは 0.0.0.0 です（実装・バージョンで表記が異なる場合があります）。127.0.0.1 のままだと「自分自身からだけ」になり、スマホからの SYN はそもそも受けません。設定を書き換えたらコアを再起動し、ログに期待した listen 行が出るか確認します。

セキュリティ上、LAN 全体にプロキシを晒すのはリスクが増えます。信頼できないゲストにまで届くネットワークでは、可能なら別 SSID・MAC 制限・短時間だけ有効にする運用を検討してください。職場や学校のポリシーに抵触しない範囲での利用を前提とします。

設定の例（環境に合わせてポートは読み替え） 
allow-lan: true
bind-address: '*'
mixed-port: 7890

OS ファイアウォールで着信を許可する

Windows

Windows Defender ファイアウォールは、初回起動時に許可ダイアログが出ないアプリでも、後からブロックされることがあります。受信規則で Clash 本体（場合によってはサービス／子プロセス）に対し、プライベート プロファイル 向けに該当 TCP ポートを許可します。セキュリティ製品を併用している場合は、同製品側でも「ローカル着信」が別ルールで落ちていないか確認してください。

macOS

アプリ署名付きの場合は「着信接続の許可」が効きますが、コマンドラインで起動しているバイナリだとルールが分かりにくいことがあります。必要に応じて「ファイアウォールのオプション」で該当実行ファイルを明示し、テスト時だけ一時的に緩めてから最小権限に戻す、という進め方が安全です。

Linux（ufw / firewalld など）

サーバ用途の Linux ではデフォルト deny が多く、LAN からの到達が FW で落ちるのは典型です。ufw allow や firewall-cmd --add-port=... で該当ポートを開けます。Docker やネットワーク名前空間を挟む構成では、ホスト側ルールだけでは足りないこともあるため、ss -lntp で実際にどのソケットが開いているかを併記して確認します。

⚠ セキュリティ：インターネット向けにポートを開放（ポートフォワード）する話とは別です。ここで言うのは 同一 LAN 内 の到達性です。ルータで WAN から LAN 管理ポートを晒す設定は避けてください。

同一サブネット・ゲートウェイ・AP 隔離を疑う

PC が 192.168.1.0/24、スマホが 192.168.43.0/24（テザリング側）のように、デフォルトゲートウェイが別 だと普通は L3 で直接届きません。PC がテザリングの DHCP を受けているか、逆にスマホが PC の共有ネットワークに参加しているか、という「誰がルータ役か」を揃える必要があります。

ホテルや公共 Wi‑Fi、社内ゲスト SSID では クライアント隔離（端末同士の通信禁止）が有効なことがあります。この場合、同じ SSID に居ても互いに ping すら通らず、プロキシ共有は設計上不可能です。自宅ルータの管理画面で隔離の有無を確認するか、隔離のないネットワークで再試験してください。

VPN を PC 側だけ張っていると、スマホのトラフィック経路とズレることがあります。切り分けのため一時的に VPN を切り、同一 LAN の素の経路だけで試すのも有効です。ルールの細部は ルール分流の考え方 と関連しますが、LAN 共有以前に「パケットが隣の端末に届くか」を先に確認してください。

スマホ側のプロキシ設定とよくある入力ミス

iOS／Android の Wi‑Fi 詳細設定で HTTP プロキシを手入力する場合、サーバ名に PC の LAN IP、ポートに mixed-port または HTTP ポートを入れます。HTTPS サイトをブラウザで見る場合でも、多くは HTTP プロキシ経由で CONNECT を張るため、まず HTTP プロキシ設定が有効かを確認します。SOCKS を使うアプリなら、SOCKS5 とポート番号の組が一致している必要があります。

よくあるミスは、PC のポートを誤って 7892 と 9090 など別物にしていること、IPv6 のみ表示されているネットワークで誤ったアドレス族を選んでいること、省電力で PC がスリープして ARP が切れたことです。長時間テストするなら PC のスリープを一時停止し、再現手順を短く保ちます。

プロキシ設定後も名前解決だけ別経路になるケースがあります。挙動が怪しいときは FAQ の DNS まわり と併せて、スマホ側の「プロキシ経由で DNS を扱う」互換を確認してください。

テザリング／モバイルホットスポット特有の注意

Windows のモバイルホットスポットや Android のテザリングでは、PC／スマホどちらが DHCP サーバになるかでアドレス帯が変わります。「PC をホットスポットの親にする」のか「スマホを親にして PC を子にする」のかで、入力すべきゲートウェイとプロキシ IP が入れ替わります。迷ったら、各端末のネットワーク詳細画面で 自分に割り当てられた IPv4 と デフォルトゲートウェイ を書き出し、同じ L2 セグメントにいるかを表にすると混乱が減ります。

キャリアの IPv6 だけが有効で IPv4 が期待と違う場合、プロキシ指定が不安定に見えることがあります。テストではまず IPv4 のみの構成に寄せると切り分けが楽です。

LAN 共有チェックリスト

順番を守ると同じ所をぐるぐるしません。

  1. PC の LAN 用 IPv4 と、mixed-port／HTTP／SOCKS の 実ポート を確定する。
  2. allow-lan と bind-address（または同等 UI）で ループバック以外 で listen しているか確認する。
  3. OS／セキュリティ製品の ファイアウォール で着信が許可されているか確認する。
  4. PC とスマホが 同一サブネット におり、ゲスト隔離 や異なるルータ配下になっていないか確認する。
  5. 別端末または nc で PC_IP:ポート の TCP 到達 を確認してから、スマホのプロキシ設定へ進む。
  6. それでも外向きだけ失敗する場合に、ノード・TLS・DNS の層へ移る（ログは前述の記事を参照）。

まとめ

Clash の LAN プロキシ共有 は、チェックを入れるだけでは完了しません。バインドアドレス がループバックのままなら外部から見えず、見えても ファイアウォール で落ち、落ちなくても サブネット不一致 や AP 隔離 でパケットが届かないことがあります。順に潰せば、スマホ側の設定ミスかインフラ要因かが素早く判別できます。

診断しやすいクライアントと、読みやすいログは、長期運用の安心につながります。ルールやノードより手前の「届く／届かない」を先に整理すると、余計なプロファイル弄りを減らせます。

→ 手元の環境に合うクライアントを選び直したい場合は、Clash を無料ダウンロードし、LAN 共有とログの両方を扱いやすい組み合わせから試してみてください。