同一Wi‑FiでPCのClash共有：allow-lanとWindows防火壁

1. ゴールと典型トポロジ

やりたいことはシンプルです。Windows 上で動いている Clash が、同一 L2 セグメント（ふつうは同じ Wi‑Fi の IPv4 サブネット）にいる他端末からの接続を受け付け、それらの HTTP(S) や SOCKS 対応アプリのトラフィックを、PC 上のコアが購読とルールに従って処理する、という形です。ポイントは「プロキシのリスナーがループバック専用になっていないか」と「OS のパケットフィルタがそのポートの TCP を落としていないか」の二段です。前者は Clash / mihomo の設定、後者は Windows の受信規則が主戦場になります。

端末側から見たプロキシサーバのアドレスは、Windows PC のその Wi‑Fi インターフェースに付いたローカル IP（例：192.168.1.23）です。127.0.0.1 は「その端末自身」を指すので、スマホの Wi‑Fi 設定に 127.0.0.1 を書いても PC 上の Clash には届きません。PC の IP は ipconfig で IPv4 アドレスを確認するか、ルータの管理画面から割当一覧を見ると確実です。固定したい場合は DHCP 予約や静的割当を検討してください。

2. セキュリティ：誰でも繋がる状態にしない

allow-lan を有効にし、かつ すべてのインターフェースでリッスンするバインド（実装やテンプレートによっては * や 0.0.0.0 に相当）にすると、同じブロードキャストドメインに参加できる端末から、そのポートへ到達できる可能性が広がります。自宅の WPA2 付き LAN でも、ゲスト用 SSID や共有スペースの Wi‑Fi では意図しない第三者が同じ空間にいることがあります。カフェや駅のフリー Wi‑Fiのように信頼できないネットワークでは LAN 共有をオンにしないのが原則です。

さらに、プロキシポートを開くと認証なしで中継点を提供しているに等しい場合があります。ルール次第ではローカルネットワーク宛の通信まで巻き込む構成もあり得るため、組織ポリシーや契約上の制限がある環境では、手順を真似る前に許諾と境界を確認してください。必要なのは「一時的に家族端末だけ」であれば、作業後に allow-lan を戻したり、受信規則を無効化する運用も合理的です。

3. まずポートを特定する（mixed-port / port）

Clash Meta / mihomo 系では、mixed-portに HTTP プロキシと SOCKS を同居させる構成がよく使われます。一方で、古いテンプレートや GUI のプリセットでは port（HTTP）と socks-port が別キーになっていることもあります。他端末に書くべき数字は「実際に LISTEN している番号」だけなので、設定 YAML の該当キーを開くか、ダッシュボードの「ポート」「接続」表示を確認してください。本稿の説明では例として 7890 を使いますが、環境ごとに読み替えが必須です。

ブラウザや OS の「システムプロキシ」がオンになっているのは、あくまでその PC 上のループバック向けであることが多く、LAN 共有の可否とは別問題です。購読の取り込みや策略の基礎はサブスクリプション導入ガイドと、ドメインの振り分けはルールルーティングの解説とあわせて押さえると、他端末から来たトラフィックがどのルールに乗るかも追いやすくなります。

4. allow-lan と bind-address（YAML と GUI）

多くの実装で、LAN からの接続を受け付けるスイッチは allow-lan: true のような boolean で表現されます。GUI クライアント（例：Clash Verge 系）では「Allow LAN」「ローカルネットワークからの接続を許可」などのチェックに相当します。これだけでは不十分な場合があり、リスナーが 127.0.0.1 にだけバインドされていると、他端末からは依然として届きません。そのときは bind-address や同等の設定で、すべての IPv4 インターフェース、または明示的に LAN IP を指定する必要があります。キー名やデフォルトはビルドとテンプレートで差があるため、手元のドキュメントと生成された設定を対照してください。

# Example fragment (keys may vary by client; replace port values)
allow-lan: true
bind-address: '*'
mixed-port: 7890

bind-address を広く取るほど到達可能範囲が増える点に注意してください。VPN や別 NIC が同時に有効なマシンでは、意図しない経路から SYN が届くケースもあり得ます。設定を書き換えたらコアの再起動または設定リロードを行い、Windows 側で netstat -ano | findstr 7890 のように LISTEN 行が 0.0.0.0 または該当 LAN アドレスになっているかを見ると安心です。

5. Windows ファイアウォール：受信の規則

Clash 側が正しく LISTEN していても、Defender ファイアウォールの受信規則が TCP ポートをブロックしていると、他端末からはタイムアウトや接続拒否になります。手順の骨格は次のとおりです。「セキュリティが強化された Windows ファイアウォール」を開き、受信の規則の新規作成でポートを選び、TCP と特定のローカルポートに 7890（実際の mixed-port）を指定します。接続を許可とし、プロファイルはプライベートに限定できるならその方が安全です。名前は分かりやすく「Clash mixed 7890」などにします。

初回起動時に「パブリックネットワークでブロックされました」系のダイアログが出て、Clash の実行ファイルごと許可リストに載ったケースもありますが、それだけではポートベースの明示規則が無いままということもあります。切り分けでは一時的に該当プロファイルで受信を許可する規則があるかを確認し、複数のネットワークプロファイルが混在しているノート PC では現在の Wi‑Fi が「パブリック」扱いになっていないかも見てください。公共ネットでは規則を絞るどころか、そもそも共有を止めるのが安全です。

サードパーティのセキュリティスイートを併用している場合は、Windows 以外のファイアウォール層が別途ポートを塞いでいることがあります。そのときは製品側のログと例外設定を確認してください。企業端末ではポリシーで変更が禁止されていることもあるため、管理者ガイダンスに従ってください。

6. スマホ・別 PC 側のプロキシ設定

Androidでは、Wi‑Fi の詳細設定からプロキシ（手動）を選び、ホストに PC の IPv4、ポートに mixed-port を入れます。iOSでは設定アプリの Wi‑Fi 詳細でHTTP プロキシを手動にし、同様にサーバとポートを指定します。アプリによってはOS のプロキシを無視して直結するものがあるため、「ブラウザだけ通る」「公式アプリだけ繋がらない」はよくあるパターンです。その場合はアプリ個別のプロキシ設定、VPN プロファイル、または別クライアントの利用が必要になります。

別の Windows / macOS / Linuxでは、システムのプロキシ設定か、ブラウザ拡張、ターミナルの HTTP_PROXY 環境変数で http://192.168.x.x:7890 の形式を指定します。SOCKS5 を使う場合はポートとスキームを合わせ、mixed-port が SOCKS も扱う構成か、別の socks-port かを必ず確認してください。DNS の扱いはクライアントによって異なり、プロキシ越しの名前解決にするかどうかで挙動が変わります。Clash 側で fake-ip や redir-host を使っている場合は、PC 上の挙動と合わせてログを見ながら調整するのが確実です。

7. 動作確認と切り分け

まず PC 自身から curl -v http://127.0.0.1:7890 のようにループバックでプロキシポートに TCP が張れるかを確認します。次に、可能なら別端末から同じ LAN の IP へ curl やブラウザで到達を試します。ここで失敗し、PC ローカルでは成功するなら、allow-lan／bind-address／ファイアウォール／別セグメント（ゲスト Wi‑Fi など）のいずれかが疑わしいです。Ping が通っても TCP ポートが閉じていればプロキシには届きません。逆に、TCP は張れるが TLS だけ失敗する場合は、ルールで CONNECT が弾かれていないか、対象アプリがプロキシ非対応でないかを疑ってください。

PC がスリープに入ると LISTEN 自体が消えるため、常時共有したいなら電源設定も見直す必要があります。ノート PC を閉じたままスマホだけ使う運用では、デスクトップや低消費電力の常時稼働マシンに Clash を載せ替える方が安定することが多いです。透明に近い挙動を求める場合は TUN モードの解説も参照できますが、LAN 共有の主題はあくまで明示的プロキシポートの開放です。

8. Docker ホスト経由記事との違い

当サイトの Docker コンテナをホストの Clash 経由にする記事では、コンテナという別ネットワーク名前空間からホストの mixed-port に届ける話を中心にしています。一方、本稿はスマホや別 PC など、人が直接操作する端末が同じ Wi‑Fi にいるケースです。どちらも「127.0.0.1 だけにバインドしていると届かない」「allow-lan が要ることが多い」という点は共通しますが、相手側の設定画面が OS の Wi‑Fi 詳細になるか、HTTP_PROXY になるかが異なります。用途が違えば記事も併読すると迷子になりにくいです。

9. まとめ

同一 Wi‑Fi で PC の Clash を家族や自分の別端末から使うには、（1）実際の mixed-port 等を確認する（2）allow-lan とバインドを LAN 到達可能にする（3）Windows の受信規則で TCP を許可する（4）クライアントに PC のローカル IP とポートを書くの四段が基本線です。途中で詰まったら、ループバックでは通るが LAN からは通らないという切り分けを軸に、設定とファイアウォールを順に疑うと早いです。信頼できないネットワークでは共有を避け、用が済んだら閉じる習慣を付けるとリスクを抑えられます。

実装が分かれていても、購読とルールで出口を整理するという発想は Clash 系で共通です。同種ツールと比べても、ログとルール表現のバランスが取りやすく、長時間の運用で差が出やすい部分だと感じる方も多いでしょう。

まずは手元の Windows に合うビルドを選び、ポートと LAN 受け入れ、ファイアウォールを一巡させるのが最短です。パッケージの入手と各プラットフォーム向け一覧は → 無料で Clash をダウンロードし、快適な接続体験を試すからどうぞ。