想定しているシーンとゴール

ノートPCやデスクトップの一台で Clash 系クライアントを動かし、同じ無線LAN（同一Wi‑Fi）にいるスマートフォン、タブレット、もう一台のPCのブラウザやアプリから、そのプロキシ経由で通信したい、というのが本稿の想定です。自宅や小規模オフィスで「ゲートウェイ機を増やさず、手元のPCを一時的なプロキシ出口にする」用途に近いイメージです。

ここでいう成功状態は、別端末のWi‑Fi設定またはアプリのプロキシ欄に、プロキシ稼働PCのLAN IPアドレスと、Clash が公開しているポート番号（多くのGUIでは Mixed Port や HTTP／SOCKS のいずれか）を入れたときに、想定どおり通信できることです。一方、本機のブラウザでは問題なく通るのにLAN側だけ繋がらない、という症状は非常に多く、その大半は「ソフトの設定」と「OS・ネットワーク機器の壁」に分けて説明できます。

よくある落とし穴：127.0.0.1 のままではLANから届かない

Clash の既定イメージでは、プロキシはループバック（127.0.0.1）向けにだけ待ち受けていることがあります。この状態では、同じPC上のアプリからは繋がっても、LAN の別マシンから届きません。LAN 共有を行う第一歩は、「待受をすべてのインターフェースに広げる」か、少なくともLAN IP にバインドすることです。

設定ファイルや一部クライアントでは bind-address が *（すべて）または実際の LAN アドレスになっているかがポイントです。127.0.0.1 のままだと、意図どおりローカル専用になります。GUI では「Allow LAN」「LAN からの接続を許可」といった名称で allow-lan に相当するトグルが用意されていることが多く、これを有効にしたうえで、待受アドレスがループバック固定になっていないかをあわせて確認してください。

設定ファイル側の確認例（allow-lan / bind-address）

コアに直接 YAML を渡している場合や、プロファイルの該当箇所だけを見たい場合は、次のようなキーが目印になります（値は環境に合わせて読み替えてください）。

# Example only — adjust ports and address to your profile
port: 7890
socks-port: 7891
mixed-port: 7893
allow-lan: true
bind-address: '*'

mixed-port を使う構成では、HTTP と SOCKS を同一ポートで扱えるため、スマホの「手動プロキシ」設定や一部アプリではこちらを指定すると手間が減ります。一方でクライアントによっては port（HTTP）と socks-port が別表示になっているため、端末側でどちらを埋めるかを取り違えないようにしてください。

Windows ファイアウォール：受信が止まっている典型パターン

allow-lan と bind を直したつもりでも、Windows Defender ファイアウォールが Clash 実行ファイルまたは該当ポートの受信を黙って落としているケースが多いです。初回起動時に「パブリック／プライベート」の選択を誤ったり、ルールが「ブロック」のまま残ったりすると、LAN からの SYN が届かないままタイムアウトします。

切り分けとしては、(1) 一時的にファイアウォールをオフにして挙動が変わるかを見る（検証後は必ず戻す）、(2)「詳細設定」から受信の規則を追加し、Clash の実行ファイル、または TCP の対象ポート（例: 7890、7893）をプライベートプロファイル向けに許可する、の順が現実的です。公共のネットワークプロファイルのままだと許可しても効かないことがあるため、Wi‑Fi のプロファイルが「プライベート」になっているかも併せて確認してください。

企業端末ではグループポリシーでローカル規則の追加が制限されていることもあります。その場合はIT部門の方針に従い、個人環境での手順をそのまま再現できない点に注意が必要です。

macOS・Linux では

macOS でも「ファイアウォール」やサードパーティ製セキュリティが受信を制限することがあります。システム設定でブロック対象になっていないか、開発用ツールと併用している場合は Little Snitch 等のアウトバウンド／インバウンドルールも疑う価値があります。Linux では ufw や firewalld、クラウド上ならセキュリティグループがLAN想定外のポートを塞いでいないかを見ます。

ルーター側：ゲストWi‑FiとAP（クライアント）隔離

同じSSIDに見えても、実はゲストネットワークに接続していると、メインネットワーク上のPCに届かないことがあります。また「AP隔離」「ステーション間通信禁止」が有効な環境では、Wi‑Fi クライアント同士がお互いにTCPを張れないため、どれだけPC側のClashを正しく設定しても失敗します。この場合はルーター管理画面で該当オプションを確認するか、試しに有線LAN同士や別SSIDへ切り替えて挙動差を見てください。

接続する側（スマホ・別PC）の設定のコツ

プロキシサーバには、プロキシPCのLAN IP（例: 192.168.1.23）と、mixed-port または HTTP／SOCKS のポートを入力します。HTTPS サイトをブラウザで開く場合、多くは「HTTPプロキシ」欄にそのまま入れれば足りますが、アプリによっては SOCKS5 を明示する必要があります。認証付きプロキシをClash側で要求していないのに、端末側だけユーザー名を入れてしまう、というミスもあるので、余計な認証情報は空にできるか確認してください。

DNS まわりで詰まるケースでは、端末がまだISPのDNSを使っており、プロキシ内の仮想DNSと噛み合わないことがあります。症状が続くときは、TUN モードでシステム全体をどう扱うかを別記事で押さえたうえで、今回の「HTTPプロキシだけ手動指定」方式と役割分担を整理すると切り分けが楽になります。

疎通の確認手順（短時間で順序を確定させる）

別端末からプロキシPCのポートが開いているかを先に確定させると、あとはアプリ設定の話に絞れます。PC側で Clash を止めた状態と動かした状態で、スマホから同じIP・ポートに接続試行し、応答が変わるかを見る方法も有効です。PC同士なら curl で --proxy を付けてHTTPの到達を試す、といった具合です。

ここでLANに届かない場合は、本章までの「bind／allow-lan」「OSファイアウォール」「ルーター隔離」のどれかに原因が残っています。逆にポート疎通はあるのにブラウザだけ失敗するなら、プロキシの種別ミスマッチやPACの残り、あるいは対象アプリがプロキシ非対応である可能性を疑います。

セキュリティと運用上の注意

LAN 向けにプロキシを広げると、同じブロードキャストドメインにいる機器から接続できる状態になります。信頼できない端末が混ざるネットワークでは、短時間の検証以外は allow-lan を閉じる、検証後は元に戻す、といった運用が安全です。また、プロキシ経由で誰かの通信を中継できる状態は、悪用されればアカウントやサブスクリプションURLの流出リスクにもつながり得ます。利用ポリシーと法令・契約を踏まえ、自分の管理下の端末に限定してください。

用語とクライアント入手について

ルールやDNS、モードの関係を押さえ直したい場合は、ドキュメントページで用語を整理すると、プロファイルのどこを触っているかが追いやすくなります。Windows をはじめ各OS向けのクライアントの入手と注意書きは、常に本サイトの導線を起点にすると、説明の粒度が揃っていて迷いにくいです。

まとめ

LAN で Clash を共有するときのボトルネックは、だいたい「待受がループバックのまま」「allow-lan が無効」「bind-address が狭い」「OS ファイアウォールが受信を落とす」「ルーターがクライアント間通信を禁止」の五つに集約されます。設定ファイルとGUIの両方を見比べ、実際のポートが端末側の入力と一致しているかを確認し、必要ならWindowsでは受信規則を明示的に足す、という順で進めると時間の浪費が少なく済みます。

単一PC内で完結する設定に比べ、LAN 共有は変数が増えますが、切り分けの型さえ持てば再現性は高いです。ほかのツールと比べても、Clash 系はポートとルールの見通しが取りやすく、同じWi‑Fi上の端末を一括で同じ出口に寄せたいときの選択肢として依然として強みがあります。

Clash クライアントを無料でダウンロードする → 各プラットフォーム向けのパッケージをまとめて確認でき、本記事の手順とあわせて初期構成まで一気に進められます。