公共 Wi-Fi の認証ページが開かない？Clash とキャプティブポータル：システムプロキシ・TUN・分流の直し方

この記事で扱う症状

空港、大型商業施設、ホテル、病院などの公共 Wi-Fiでは、接続直後にブラウザで規約同意や会員ログイン、場合によっては QR コード連携まで求められることがあります。これはいわゆるキャプティブポータル（Captive portal）による認証ページ表示の流れです。ところがノート PC で Clash（Mihomo／Meta 系コアを載せた GUI 含む）を起動し、システムプロキシや TUN（仮想 NIC によるトラフィック取り込み）を有効にした状態だと、そもそもログイン画面が開かない・ずっと読み込みのまま・認証ボタン後もインターネットに出られない、といった事象が起きやすくなります。

本稿では、原因を「購読切れ」や「ノード全滅」より前に、ポータル検出用の HTTP リクエストがプロキシ経路に乗ってしまうこととして切り分け、現場で再現しにくい順に手順を並べます。クライアントのメニュー名は製品ごとに異なりますが、考え方は共通です。

なぜ Clash を入れるとポータルが壊れやすいか

多くの OS やブラウザは、Wi-Fi 接続直後に小さな HTTP リクエストで「インターネットにそのまま出られるか」を確認します。アクセス先はベンダーごとに異なりますが、未認証の場合はゲートウェイ側が 302 などのリダイレクトで施設固有の認証 URLへ誘導し、そこでログイン完了後に本線へ出します。このとき、システムプロキシが Clash のローカルポートを指していると、接続チェック自体が「プロキシ越し」の経路になります。ルール次第ではその通信が遠隔のプロキシノードへ送られ、施設側ゲートウェイが期待する同一 L3 上のリダイレクトと整合しなくなります。

TUN を有効にすると、対象トラフィックがさらに広くコア側へ吸い上げられるため、DNS や fake-ip の設定と組み合わさると「名前は解けたように見えるが実体の経路がポータルと噛み合わない」状態にもなり得ます。つまり公共 Wi-Fi では、認証が終わるまでの短い時間だけでも「ローカル側の直結（DIRECT）」を優先するのが安全です。

用語：分流は、ドメインや IP に応じて DIRECT（ISP／施設ゲートウェイ直出し）とプロキシグループを振り分ける Clash の基本動作です。キャプティブポータル対策は、特定ホストやプライベート帯を MATCH より手前に DIRECT で置く「ミニ分流」と考えると整理しやすいです。

ステップ 1：認証前は Clash を「通さない」状態へ

最も確実なのは、ポータル認証が完了するまで Clash を一時停止することです。具体的には次のいずれか、または併用です。（1）アプリのメインスイッチでコアを止める（2）システムプロキシの自動設定をオフに戻す（3）TUN モードをオフにする。Windows や macOS の「プロキシを手動で指定」が残っていると、Clash を閉じてもブラウザだけ別経路になるなど不整合が出るため、OS 側のネットワーク設定も一度確認してください。

モバイルテザリングで別回線を確保できるなら、認証用ブラウザだけその回線に切り替え、認証後に公共 Wi-Fi へ戻す方法もあります。いずれにせよ「キャプティブポータル検出 → リダイレクト → ログイン POST」までの一連が、施設ゲートウェイと同じ経路を通ることが目的です。

ステップ 2：ルールで「検出・ポータル系」を直結へ（上級者向け）

外出先で毎回アプリを止めたくない場合は、プロファイルの rules: の上位に、接続チェックやよくあるポータルドメイン、施設が案内するログイン URL のホストを DIRECT で列挙します。さらに IP-CIDR,10.0.0.0/8,DIRECT や 192.168.0.0/16、172.16.0.0/12 のようなプライベート帯を DIRECT にする構成も、ポータルがイントラ内 IP に飛ばすケースで有効です。ただし職場 VPN や分割トンネルと衝突することがあるため、常設ルールとして入れるかは用途次第です。

ルールの書き方や優先順位の考え方は、ルール分流の日本語ガイドで DOMAIN／IP-CIDR の並べ方を押さえておくと安全です。MATCH が最下行でプロキシグループに落ちる典型構成では、その直前にポータル用 DIRECT を挟むイメージになります。

ステップ 3：DNS・Fake-IP・TUN のすり合わせ

Fake-IP モードでは、名前解決結果が一時的に仮想アドレスになります。通常サイトでは問題になりにくい一方、ポータルやイントラ向けの名前が意図せず遠隔 DNS へ問い合わされ、施設内の正しい A レコードとズレることがあります。症状が「ページは出るが証明書エラー」「別施設のログイン画面に飛ぶ」に近いときは、認証中だけ fake-ip を切る／nameserver-policy で該当サフィックスをローカル DNS へなど、DNS セクションの見直しが有効です。

TUN では strict-route やスタック実装によって、ローカルサブネットへの戻り経路が変わる場合があります。TUN モードの解説で、自環境における「どのトラフィックが仮想インターフェースに乗るか」を確認したうえで、ポータル通過時は TUN をオフにするか、クライアントが提供する「バイパス」相当の設定を活用してください。

ステップ 4：認証後に Clash と分流を戻す

ログイン完了後、ブラウザで一般的なサイトが開けることを確認してから、システムプロキシや TUN、ルールプロファイルをいつもの運用に戻します。いきなり「ルールモード＋大量の remote rule」へ戻すと、まだセッション確立前の短い窓で再び詰まることがあるため、最初は動作確認用の軽いプロファイルから段階的に戻すと安心です。

公共 Wi-Fi は出口や DNS が施設側ポリシーに依存するため、プライベートな通信は可能なら VPN や信頼できるノードへ集約し、ポータル検出だけを DIRECT に残すような分流設計が現実的です。同じ端末で LAN 共有や WSL2 を併用している場合は、経路が多重化しやすいので、WSL2 と Clash のルーティング記事や Allow LAN 系の稿とあわせて読むと、切り分けの軸が増えます。

その場ですぐ試せるチェックリスト

  1. Clash を止め、OS のプロキシ設定が「オフ／自動検出のみ」になっているか。
  2. TUN・システムプロキシの両方がオフの状態で、未認証 URL にリダイレクトされるか。
  3. 認証後、同じ SSID のまま一般サイトが開くか（別タブで確認）。
  4. Clash を戻したあと、意図したプロキシグループにトラフィックが乗っているか（ログ／接続一覧）。
  5. DNS クエリが施設側・自前のどちらを向いているか（コアの DNS ログがあれば参照）。

運用のコツ：「外出用」と「自宅用」でプロファイルを分け、外出用だけプライベート帯 DIRECT を厚めにする方法があります。ルールを増やしすぎると保守が難しくなるので、よく止まる施設チェーンのドメインだけをメモし、RULE-SET やローカルリストに段階的に足すのが現実的です。

ドキュメントと入手先

YAML の細部や用語は、当サイトのドキュメント集も参照してください。クライアントのビルドは分岐しやすいため、説明の一貫した導線としてダウンロードページを主な入手先にすると取り違えが減ります。

まとめ

公共 Wi-Fi のキャプティブポータルは、接続チェック用の小さな HTTP が施設ゲートウェイ上でリダイレクトされる前提で成り立っています。Clash のシステムプロキシや TUN が有効だと、その通信がプロキシ出口側に流れ、検出やログイン POST が噛み合わなくなるのが典型です。対策の核は、認証完了までの間だけ直結を最優先にすることであり、アプリ停止が最速、常時運用ならルール上位の DIRECT と DNS の整合が次の手段になります。

認証後はいつもの分流に戻してよいですが、施設 DNS の制約を踏まえ、プライバシーが気になる通信は引き続き信頼できる経路へ寄せる設計が無難です。ルールと TUN の両方を扱える点で、Clash／Mihomo 系は現場の切り替えがしやすいのが強みです。

各 OS 向けクライアントはダウンロードページにまとめています。公共 Wi-Fi で手順を一度通したうえで、自環境に合う GUI を選ぶと、同種のトラブルへの立ち戻りが速くなります。→ Clash クライアントを無料でダウンロードし、外出先でも切り替えやすいプロファイル運用を整える