この記事でできること

すでに Clash Verge Rev(Mihomo コアを使うデスクトップ向け GUI)が Windows で動いていて、同じ家庭内 LAN やオフィス Wi‑Fi にいる他の端末から、その PC を「プロキシの出口」として使いたい、という状況を想定しています。ごく一般論として「共有」は便利ですが、設定を誤ると自分の PC がローカルネットワーク全体から到達可能なプロキシ開口部になるため、allow-lan をいつオンにするか、どのポートを開けるか、は慎重に扱う必要があります。

ここでは長文の YAML をゼロから書くのではなく、GUI と一般的な用語に寄せて、mixed-port(混合ポート)で HTTP と SOCKS をまとめて扱う流れと、LAN 側から接続するときのIP アドレスとファイアウォールの観点を整理します。利用環境のバージョンによってメニュー名称が若干違っても、コアの概念は共通なので、画面が変わった場合は同種の項目を探してください。

mixed-port と allow-lan を日本語の感覚で押さえる

mixed-port は、ひとつの TCP ポート上で HTTP CONNECT 方式のプロキシSOCKS5の両方を受け付けるための「統合待ち受け口」です。クライアントアプリによっては HTTP プロキシしか設定できないものと、SOCKS5 を要求するものに分かれるので、番号が二つに増えると LAN 上の端末ごとに覚える項目が増えてしまいます。混合ポートを基準に番号を一つに寄せると、スマホの Wi‑Fi 詳細設定やテレビのネットワークメニューに入力する数字が揃い、運用ミスが減ります。

一方 LAN からの接続を許可する設定は、設定ファイル上では歴史的に allow-lan と書かれることが多く、GUI では「LAN からの接続を許可」「Allow LAN」などのトグルとして出ます。これがオフのとき、待ち受けは多くの場合 127.0.0.1(ループバック)に限られ、同じ PC 上のアプリからは使えても、隣のスマホからは到達できません同一 LAN 内で共有する第一歩は、このスイッチとバインド先の理解です。

始める前の確認:セキュリティとネットワーク境界

allow-lan をオンにすると、同じブロードキャストドメインにいる機器からあなたのプロキシポートへ到達できる可能性が高まります。信頼できないゲスト Wi‑Fiカフェのフリー接続では、わざわざ LAN 全体にポートを広げない方が安全です。自宅のルーター裏で端末台数が限られている、社内の閉じた VLAN である、モバイルホットスポットで自分の電話だけを繋いでいる、といった境界がはっきりしている場面で使い分けるのが実務的です。

また、プロキシを「中継点」にしただけでは、クライアント側アプリがプロキシ非対応の場合は効きません。ブラウザは比較的簡単ですが、ゲーム機や一部のテレビアプリは SOCKS を取れない機種もあります。そうしたときは端末 OS のプロキシ設定が効く範囲に収まることを事前に確認してください。

ステップ 1:Windows PC の LAN 側 IP を固定して把握する

他端末から指定する「プロキシのホスト名」は、共有元 PC の LAN 上の IPv4 アドレスです。コマンドプロンプトで ipconfig を実行し、今つながっている Wi‑Fi またはイーサネット アダプターの「IPv4 アドレス」をメモします。DHCP だと再起動で変わることがあるため、ルーター側でDHCP による IP アドレス予約を付けるか、問題が起きたら再確認するクセを付けるとよいです。

Windows のモバイルホットスポットを出している場合、ホスト PC はゲートウェイ兼配布側となり、接続したスマホから見る「PC の IP」はホットスポット用インターフェースに割り当てられた番号(しばしば 192.168.137.1 のような値)になります。環境ごとに違うので、実際に ipconfig で表示された値を信じてください。ここを推測ミスすると、クライアントは一切繋がりません。

ステップ 2:mixed-port の実際の数値を読み取る

Clash Verge Rev では、アクティブなプロファイルの概要や「設定」「コアのポート」周辺に、現在の混合ポート番号が表示されます。カスタムの上書きで値を変えている場合は、デフォルトからずれている点に注意してください。古いドキュメントに「HTTP は 7890、SOCKS は 7891」と書いてあっても、今のプロファイルが mixed-port のみを使う構成なら、クライアントはその一つの番号だけを見れば足ります。

もし mixed-port が無効で分離ポートになっている構成なら、端末が HTTP なのか SOCKS なのかに合わせて片方だけを開くことになります。初心者向けには、mixed-port に寄せて一本化してから LAN 共有に進むと、トラブルシュートが一段簡単になります。

ステップ 3:Allow-LAN(allow-lan)をオンにし、待ち受けを確認する

アプリの設定画面で LAN 接続を許可する項目を探し、オンにします。併せて、コアが 127.0.0.1 だけに拘束されていないかを確認してください。多くの環境では、allow-lan オンで 0.0.0.0(任意インターフェース)待ち受けとなり、同じサブネットの機器から PC の LAN IP:mixed-port 宛て TCP が届くようになります。企業ポリシーやサードパーティのセキュリティ製品が着信を止めている場合は、そちらの例外も必要になることがあります。

重要: allow-lan は便利機能ですが、悪意ある同一 LAN 内の機器から悪用されるリスクもゼロではありません。信頼できるネットワークかどうかを切り替える運用を心がけ、不要なときはオフに戻す習慣を推奨します。

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

設定が正しくても、OS が着信 TCP を黙殺している典型例がファイアウォールです。初回起動時に「パブリック/プライベート」の選択で誤ってブロックした場合や、手動規則が古いまま残っている場合もあります。次のような順で切り分けます。

  • アプリルール:Clash Verge Rev の実行ファイルに「プライベート ネットワークでの受信を許可」があるか
  • コア実行体:Mihomo のバイナリ名で別プロセスになっている場合、その実行ファイルにも同様の許可が必要なことがある
  • ポート開放が必要なら:TCP の mixed-port に対し、スコープをプライベート(家庭・職場)ネットワークに限定した受信規則を追加する(全世界的に開かない)

管理者権限の UAC ダイアログで誤って拒否すると、仮想 NIC やリバースプロキシ系の挙動が不安定になることもあります。変更後は Verge Rev を一度終了してから再起動し、タスクマネージャーに古いコアが残っていないかも見てください。

ステップ 5:クライアント端末に HTTP/SOCKS を入力する

Android では Wi‑Fi の詳細設定に「プロキシ:手動」があり、ホストに PC の LAN IP、ポートに mixed-port を入れます。プロキシ種別が HTTP と SOCKS で分かれている UI なら、試す順序としては HTTP を先に、ダメなら SOCKS5 を試すのが無難です。iOS も Wi‑Fi ごとに HTTP プロキシを設定できますが、挙動はアプリによってバイパスされることがあるため、まず Safari で確認するとよいです。

テレビやゲーム機はメニュー名がメーカー依存ですが、「手動」「アドレス指定」とあれば同じく PC の IP とポートです。認証を求められる UI の場合、Clash 側で認証を有効にしていなければユーザー名は空のままにしてください。

モバイルホットスポットと「傍路」の一歩手前の話

外出先でノート PC のホットスポットを張り、スマホだけを繋ぐ構成は、事実上クローズドに近い LAN になります。ただしホットスポット利用時はデータ通信量が PC 側に集約される点、省電力設定で PC がスリープに落ちると途切れる点に注意してください。また、テザリング先端末が「プロキシ設定なし」のままだと通信は直接出ていくため、プロキシ環境変数や OS の Wi‑Fi 設定の両方を運用ルールとして揃えないと、期待した経路にならないことがあります。商用 VPN と同時に有効化すると競合する例もあるため、切り分けのときはどちらか一方に寄せて試します。

疎通の確認と典型トラブル

まず共有元 PC 自身のブラウザでプロキシ経由の疎通を確認し、その後クライアントへ移ると原因の切り分けが速いです。LAN から繋がらないときは、(1) IP の取り違え、(2) allow-lan オフまたはループバック拘束、(3) ファイアウォール、(4) プロファイルが無効でコア未起動、(5) ポート番号の取り違え、の五つをほぼ機械的に確認できます。ping が通ってもプロキシの TCP が通らない、というパターンはファイアウォールが典型です。

また、一部のキャプティブポータル付き Wi‑Fi では、DNS やリダイレクトの挙動が特殊で、プロキシ前提の端末だけ挙動がおかしくなることがあります。そうした場所ではまずポータル認証を通常ブラウザで完了してからプロキシ設定に進むと安全です。

よくある質問(本文)

Q. ルール分流はクライアント側にも効きますか?

A. トラフィックが PC 上の Mihomo コアに入れば、その時点でプロファイルのルールが適用されます。クライアント側で追加ルールは要りません。ポリシーグループでどのノードへ出すかは、共有元 PC の画面と同じ考え方です。

Q. IPv6 だけの環境でも使えますか?

A. 家庭ルーターでは IPv4 と IPv6 が混在していることが多く、スマホが IPv6 優先でも最終的にプロキシのホストへは IPv4 で届くケースが大半です。うまくいかないときは、PC とクライアントの双方で有効なアドレスファミリを確認し、ルーターの設定と合わせてください。

なぜ「一台で束ねる」設計に Clash 系が向くか

端末ごとに別々の VPN アプリを入れ、それぞれでサブスクリプション URL を管理するやり方は、ライセンスやログイン制限の都合で場つなぎには有効ですが、ルールの一貫性更新の手間はすぐに限界が見えます。スマホ用アプリがストア規約で不安定になりやすい一方、PC 上の Clash Verge Rev はファイルとコアの関係がわかりやすく、allow-lan と mixed-port を踏まえた LAN 共有なら、余った端末を追加コスト小で同じポリシーに載せ替えられます。もちろん万能ではなく、端末全自動VPNほど「気にしなくていい」わけではありませんが、技術者や映画の大容量視聴、開発用の検証端末など、出口を一つに集約したい用途では現実的な落としどころです。

チュートリアルで記載したノード切り替えやルールセットの思想を、そのまま LAN 越しに共有できる点も、単発のプロキシツールより扱いやすい強みです。複数 OS にまたがる公式クライアントを探すより、まず一台の Windows で安定した出口を作り、周辺機器を徐々に載せていく進め方は失敗しにくいでしょう。

Clash を無料ダウンロードして、スムーズなプロキシ運用を試す →