よくある症状とゴール

Windows 11 の PC では Clash／Mihomo 系クライアントが問題なく動いているのに、同じルーター配下のスマートフォンやタブレット、メディアボックスから HTTP プロキシや SOCKS で PC に接続しようとするとタイムアウトする。あるいはブラウザだけ通るがアプリは繋がらない、海外サイトだけ開けない、といった部分的成功が出る、という相談は非常に多いです。

本記事のゴールは、「LAN 内の別端末から PC のプロキシポートへ TCP で届いているか」を、設定ファイル・GUI・OS・ルーターの順に切り分けることです。分流ルールや購読そのものの話ではなく、到達性（リーチャビリティ）に焦点を当てます。ノードや DNS の詳細は fake-ip／redir-host の記事 や DNS まわりのガイド と併読すると整理しやすいです。

ステップ 0：本当に同じ LAN にいるか

まず、PC とモバイル端末の IPv4 アドレスが同じプライベート帯にあるか確認してください。例えば PC が 192.168.1.10、スマホが 192.168.1.24 のように、第 3 オクテットまで揃っているのが一般的です。スマホが 10.x 系の「キャリアグレード NAT」や、ゲスト Wi-Fi 用の別サブネットにいると、たとえ同じ SSID 名でもレイヤ 3 で別ネットワーク扱いになり、PC のポートに届きません。

また、USB テザリングで PC だけ有線／別回線に出している場合、Wi-Fi 側の端末からは PC の「Wi-Fi インターフェースのアドレス」ではなく、別経路を見ていることがあります。トラブル時はいったん「同じ SSID・同じセグメント」に揃えてから再現テストするのが近道です。

ステップ 1：allow-lan を有効にする

Clash 系コアでは、既定ではループバック（同一マシン内）からの利用だけを想定していることがあり、LAN からの接続を許可するスイッチが allow-lan です。GUI の「Allow LAN」「LAN に許可」などのチェックがオフのままだと、ファイアウォール以前にアプリケーションがそもそも待ち受けていない状態になります。

設定ファイルで明示する場合の例は次のとおりです（実際のキー名はクライアントの世代で多少異なるため、手元のテンプレートと照合してください）。

# Excerpt — verify keys against your client template
allow-lan: true
bind-address: '*'
mixed-port: 7890

allow-lan: false のまま mixed-port だけ触っても、LAN 側からは繋がりません。変更後は設定の再読み込みまたはクライアントの再起動を忘れずに。

ステップ 2：待受アドレス（bind-address／listen）を確認する

allow-lan をオンにしても、待受が 127.0.0.1 に限定されていると、他端末からは届きません。多くの環境では bind-address: '*' または 0.0.0.0 相当の「すべてのインターフェースで待つ」指定が必要です。逆に、セキュリティ上の理由でローカルのみに縛りたい場合は意図的に 127.0.0.1 にすることがありますが、その状態では LAN 共有の目的と矛盾します。

ノート PC で有線と Wi-Fi を同時に使っている場合、どのインターフェースの IPv4 をスマホ側に書くかも重要です。プロキシ設定には「その時点でスマホと同じサブネットにある NIC の IP」を入れます。VPN や仮想アダプタが増えると、GUI が表示する IP と実際の経路が食い違うことがあるので、Windows の「ネットワークの詳細設定」で一覧を確認してください。

ステップ 3：ポート番号とプロトコル（mixed／HTTP／SOCKS）

モバイル側の Wi-Fi 設定やプロキシアプリに、PC の LAN IP と 正しいポート番号を入れます。mixed-port が有効なら HTTP と SOCKS の両方が同じポートで扱える構成が多いですが、クライアントによっては http-port と socks-port が分かれているので、GUI の表示どおりに埋め込んでください。

よくあるミスは、(1) 古いポート番号のまま固定している、(2) 別プロファイルを読み込んでポートが変わった、(3) システムプロキシは 7890 なのにアプリだけ別ポート、です。PC 側で netstat やリソースモニタを見て、意図したポートが LISTENING になっているかを確認すると確実です。

ステップ 4：Windows 11 ファイアウォールで受信を許可する

アプリ設定が正しくても、Windows Defender ファイアウォールが Clash 実行ファイルの受信をブロックしていると、LAN からの SYN が届いた時点で黙殺されます。初回起動時に「パブリック／プライベート」のどちらで許可するか聞かれてパブリックのみブロック、というパターンもあります。

対処の流れは次のとおりです。(1)「セキュリティの Windows」→「ファイアウォールとネットワーク保護」→「詳細設定」で受信の規則を開く。(2) 該当する Clash／Verge 等の実行ファイル、または使用ポート（TCP）に対する許可規則があるか確認する。(3) 現在のネットワークが「プライベート」か「パブリック」かに合わせてプロファイルを選ぶ。(4) テストのため一時的に受信を許可し、通ることを確認してから必要最小限に絞る。

社用 PC やドメイン参加マシンでは、グループポリシーで上書きされていることもあります。その場合は個人設定だけでは開かず、管理者に「指定ポートのインバウンド」を依頼する必要があります。TUN ドライバまわりの別トラブルは Windows TUN／Wintun の記事 も参照してください。

セキュリティ上の注意：LAN 全体にプロキシを開くと、同じネットワークにいる機器からアクセス可能になります。信頼できないゲストを載せた Wi-Fi では allow-lan をオフに戻す、またはルーター側でゲスト隔離を有効にするなど、運用とセットで考えてください。

ステップ 5：ルーターの AP 隔離・ゲスト SSID・メッシュ

近年の家庭用ルーターには、クライアント隔離（AP isolation）やゲストネットワークがあり、同じ SSID でも端末同士の通信を禁止するモードがあります。これがオンだと、スマホから PC の LAN IP へ ping すら通らないことがあります。管理画面で該当オプションをオフにできるか、スマホを「メイン LAN」側の SSID に付け替えてください。

メッシュ Wi-Fi や中継器では、バックホールの構成によっては期待したセグメントにいないケースもあります。疑わしいときは、ルーターと PC・スマホを同一レイヤ 2 セグメントに寄せてから再テストすると切り分けが速いです。

「一部だけ繋がる」とき：DNS とルールの話

プロキシ自体は通っているのに、特定ドメインだけ失敗する場合は、LAN 到達性ではなく名前解決やルール順の問題であることが多いです。モバイル側で「プロキシを経由せず DNS だけローカル」になっていると、期待した経路とズレます。PC 側で fake-ip とルールを調整している場合は、スマホのブラウザ拡張や「プライベート DNS」も一時オフにして比較してください。

iPhone や iPad で同様の切り分けをする場合は、iOS 向けの購読・接続ガイド の「ローカルネットワーク」や VPN 権限の章も併せて読むと、モバイル特有の落とし穴が整理しやすいです。

最短チェックリスト（コピー用）

  • 同一サブネット：PC／スマホの IPv4 が同じプレフィックスか。
  • allow-lan: true：GUI と YAML の両方を確認し、再読み込みしたか。
  • 待受が LAN 向け：127.0.0.1 専用になっていないか。
  • ポート一致：mixed-port または分離ポートを端末側に正しく入力したか。
  • Windows FW：受信規則で Clash 実行ファイル／該当 TCP ポートが許可されているか。
  • ルーター：AP 隔離・ゲスト Wi-Fi で端末間通信が禁止されていないか。

まとめ

LAN 共有でつまずく原因は、大きく分けてアプリが LAN 向けに待ち受けしていない、OS のファイアウォールが受信を落としている、ルーターが端末間通信を禁止している、の三つに集約されます。まず同一ネットワークであることを確認し、allow-lan と待受アドレス、ポートを揃え、Windows 11 側の受信規則とルーター設定を順に潰していくと、迷子になりにくいです。

コアのソースやライセンスを確認したい場合は GitHub の公式リポジトリが参照先になりますが、日々のインストールと更新の導線は、検証済みパッケージがまとまっている公式の入手ページに寄せると手戻りが少なくなります。関連トピックは 技術ブログの一覧 から辿れます。→ Clash を無料ダウンロードして、自宅 LAN での共有構成まで含めて試す