なぜ「認証が終わるまでClashが使えない」ように見えるのか

学内Wi‑Fiの多くは、未認証端末からの通信を一時的にキャプティブポータルへ集約します。ブラウザが最初に開くページ、大学のSSO、リダイレクト連鎖、場合によっては専用アプリや証明書まで含みます。ここで重要なのは、「どのホスト名へ、どの経路で到達すべきか」が通常のインターネットとは異なるという点です。

Clashは、設定どおりにトラフィックをプロキシグループへ振り分けます。ところが認証前は、本来ローカル側で完結すべきHTTPセッションまでが海外ノードへ送られたり、学内DNSの返答とクライアント側の名前解決モードの組み合わせが噛み合わず、ページが白紙のまま止まったりします。ユーザーから見ると「Clashをオンにすると学内が死ぬ」「オフにするとだけ繋がる」という二択のトラブルに見えますが、多くはルール順とDNSの整理でかなり緩和できます。

また、購読リンク（サブスクリプションURL）の取得も、ポータル下ではHTTPSが別物に見えることがあります。設定画面では「更新失敗」や空のノード一覧に見えても、根本原因はClashではなくまだ認証が通っていないケースが混ざります。まずは認証を終え、通常ブラウジングが成立してから購読を更新する、という順序が安全です。購読まわりの切り分けは購読の自動更新が失敗するときの記事とも整合します。

ステップ1：Captive Portalを「Clashなし」で完走させる

最初の一手はシンプルです。システムプロキシ／TUNを含むClash系の転送をいったん止め、OS標準の経路だけでポータルを開くことです。Windowsならタスクバーのネットワーク一覧から「ログインが必要」と出たSSIDを選び直す、macOSならキャプティブウィザードに任せる、スマホなら通知からポータルへ入る、といったメーカー推奨の入口を使うと失敗が減ります。

ここでやりがちなのが、「とりあえずブラウザで任意のサイトを開く」だけで終わらせてしまうことです。学内によってはHTTPSのみのサイトでは検出が遅れるため、意図的にhttp://で到達できる検出用URLを叩く運用が安定します（大学ごとに案内がある場合はそれに従ってください）。ポータルが開いたら、利用規約の確認や二要素認証まで含めてセッションが張れた状態まで進めます。

この段階ではまだClashのYAMLをいじる必要はありません。むしろ変数を一つに絞ることが目的です。「ポータルが開かない」の原因が、Wi‑Fiそのものなのか、Clashなのか、DNSなのかを分離するため、最初はプロキシを完全に外した状態で成功を確認します。

ステップ2：ルールの先頭に「認証・ポータル・RFC1918」を直結（DIRECT）で積む

認証が通ったらClashを起動しますが、そのまま購読の巨大なRULE-SETだけに任せると、学内ドメインが海外出口へ流れることがあります。Clashのrulesは上から順に評価され、最初に当たった一行だけが採用されるため、例外は必ず上です。分流の基本はYAMLルール分流の解説で詳しく扱っていますが、学内では次のような「短くて明確なブロック」を自分用に足すのが効きます。

  • 大学ポータルやSSOのドメイン：分かる範囲でDOMAIN／DOMAIN-SUFFIXを列挙し、いったんDIRECTへ。
  • RFC1918のプライベート範囲：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16などをIP-CIDRで直結。イントラのファイル共有や実験室LANに触れる場合は必須級です。
  • キャプティブ検出用の既知ホスト：端末OSが参照する名前が分かるなら、同様にDIRECTへ。

ポイントは「購読ルールのどこに挿すか」です。GUIによっては「カスタムルール」欄が自動的に先頭へ付く実装もあれば、単純に末尾へ足すだけの場合もあります。実際の並びをエクスポートしたYAMLで確認し、自分の直結行がGEOIPや広いMATCHより上にあることを必ず目視してください。ここがズレると、見た目は同じ設定でも挙動がまったく変わります。

# Example: put campus-specific DIRECT rules above broad proxy rules
rules:
  - DOMAIN-SUFFIX,campus.example.jp,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  # ... subscription RULE-SET lines ...

大学ごとに正式なドメイン名は異なるため、上の例は構造のたたき台です。実際には情報システム課のマニュアルや、接続テスト時のブラウザ開発者ツールで見えるホスト名をメモし、少しずつDOMAIN行を増やすのが現実的です。

ステップ3：購読ルールセットとの「順序競合」を潰す

多くの購読プロファイルは、海外SNSやストリーミング向けのRULE-SETを同梱します。便利な一方で、学内ドメインまで広いカテゴリに含まれてしまうと、意図せずプロキシへ送られます。対策は二つあります。

第一に、前述のとおり手書きの直結ルールを物理的に上へ。第二に、購読側のRULE-SETを丸ごと疑い、ヒットしたルール行をログで確認することです。クライアントのログに「matched rule」や「policy」が出る場合は、その行が本当に望むものかをチェックします。分流設計の考え方は使い方ガイド（ヘルプ）の「ルールモード」周辺とも整合的です。

ときどき、「GEOIP,JP,DIRECTのような行があれば安心」という期待をしますが、学内アドレスが必ずしも日本のGEOIP判定に乗らないこともあります。学内はプライベートアドレスや独自ASNの外側に見える経路があり、GEOIPより前のIP-CIDRの方が確実な場面が多いです。

ステップ4：DNS（fake-ip／redir-host）でポータルとイントラを壊さない

ルールが正しくても、名前解決の段階で期待と違うIPが返ると、ブラウザは別のサーバへ接続してしまいます。Clashではdnsセクションのenhanced-modeとしてfake-ipとredir-hostが代表的です。パフォーマンス重視ならfake-ipが有利ですが、キャプティブポータルやイントラの挙動ではredir-hostの方がトラブルが少ない、という整理がよく使われます。

実務では、まず症状を見ます。ポータルだけ開かない、学内VPNの名前が解決しない、証明書警告が増える、といったときはDNSモードの切り替えや、特定ドメインだけ実解決へ寄せるnameserver-policyを検討します。手順の骨格はDNS fake-ipとredir-hostの記事に任せるのが早いです。学内シナリオは「ローカル名前」と「ポータル検出」が絡む点で、同じトラブルシュートの枠組みに収まります。

また、TUNモードと併用すると、DNSの問い合わせ経路も変わります。システムプロキシのみのときは問題なくても、TUNで初めて表面化することは珍しくありません。モード変更の影響はTUNとシステムプロキシの比較記事で整理している通り、切り分けの順序が重要です。

ステップ5：ヘルスチェックURLと「いつ購読を更新するか」を学内向けに合わせる

自動選択系のプロキシグループは、到達確認用のURL（url-testのurlなど）を叩きます。デフォルトが海外のgenerate_204系だと、学内ではまだブロックされている間にすべてのノードが不健康に見えることがあります。寮に入った直後は、まずDIRECTで一般サイトが開けるかを人間が確認し、その後に自動選択へ、という順が安全です。

購読の更新タイミングも同様です。購読が取得できないときは、TLSやUser-Agentの話に飛びがちですが、学内ではそれ以前にCaptive PortalのHTMLがYAMLとして保存されてしまうことすらあり得ます。ブラウザで購読URLを開いて中身が期待どおりかを見る、という素朴な確認が有効です。そして認証後に再更新すれば、ノード一覧が正常に戻ることが多いです。

長期運用では、学内と自宅でプロファイルを分ける、あるいはproxy-groupsに「学内モード（ほぼDIRECT）」を用意する、といった運用の分離も検討に値します。設定の複雑さは増えますが、「接続したSSIDで挙動が変わる」という現実に合わせると、トラブルの説明が家族やルームメイトにもしやすくなります。

よくある質問

学内ではUDPやVPNプロトコル自体が止まりますか？

場所によっては、UDPや非標準ポートに厳しいポリシーもあります。本稿の焦点はCaptive Portalとルール順ですが、全ノードがタイムアウトする場合は、別レイヤーの制限も疑ってください。モバイル向けの切り分けはAndroidのノードタイムアウト記事が参考になります。

OpenWrtでルーター側Clashを使っている場合は？

ゲートウェイとPCクライアントを併用すると、DNSやデフォルトルートの責任が二重になります。ルーター運用との共存の話はOpenWrtとデスクトップClashの共存記事を参照し、学内SSIDではクライアント側を単純化する、といった整理も有効です。

「直結は分かるが、どのドメインを書けばよいか分からない」

最初から完璧を狙わず、接続に失敗したサイトのホスト名をログに残し、一つずつDIRECTへ追加するのが現実的です。学内の情報システムが公開している「プロキシ環境下の注意」も併せて読むと、ドメインのヒントが得られることがあります。

まとめ

学内Wi‑FiでClashが不安定に見えるとき、原因は単一ではありません。それでも対処の軸ははっきりしています。Captive Portalを先に完走させること、ルールの上から順に学内向けの直結を置くこと、DNSモードを症状に合わせること、そして購読の更新は認証後の健全なHTTP経路で行うことです。この四つがそろうと、「Clashをオフにしないと学内に入れない」状態から大きく距離を置けます。

クライアントの見た目は製品ごとに違っても、YAMLのrulesとdnsの考え方は共通です。安定したコアと分かりやすいGUIを選び、設定をエクスポートして自分の優先順位を確認できると、次の学期のネットワーク変更にも強くなります。

→ Clashを無料ダウンロード — Metaコア対応の各クライアントを一覧から選び、学内と自宅で同じ分流思想を試せます。

ほかのチュートリアルや最新記事は 技術コラム からどうぞ。