なぜ「全部プロキシ」が学習シナリオで噛み合わないか

国境をまたいだ学習環境では、「とりあえずシステム全体を迂回ルートに寄せる」方式が一見、簡単に見えます。しかし大学の シングルサインオン（SSO） や図書館の プロキシ認証、キャンパス内だけ開放される イントラ向けDNS は、名前解決や経路が変わると静かに失敗します。住所がローカル側にしか存在しないドメインを、意図せず遠隔リゾルバへ問い合わせたり、学内証明書を提示すべき経路が匿名ノード側へ逃げたりすると、症状は「ログイン画面がループする」「PDFが真っ白」「課題提出フォームだけ届かない」といった局所的な形に出がちです。

一方で、講義動画や協働ツール、論文データベース、コードホスティングは、キャンパス外からの到達性や帯域の都合で 迂回が安定する ことも珍しくありません。この二種類のトラフィックを同じ一本のデフォルトルートに押し込むと、どちらかが常に困ります。Clash 系は ルールベースの分流 が得意なので、「学内らしき宛先は早い段階で DIRECT に落とし、学習コンテンツだけ選択的に迂回する」という設計に寄せるのが現実解です。基本の評価順は ルール分流のベストプラクティス と同じで、上の行からマッチします。

ℹ 用語の整理：GUI の「プロファイル」と、設定 YAML の profile: ブロック（ノード選択の保存など）は別物です。本稿では主に 利用場面ごとの設定束（Profile） を指します。mixin でベースに差分を重ねる考え方は mixin 併合の記事 と相性が良いです。

設計ゴール：共有購読とデバイス別の動作パターン

まず購読 URL は更新負担を減らすために共有し、挙動の束 は端末ごとに分けるのがバランス良いです。ノートPCは長時間の講義視聴、IDE からのクローン、LaTeX ビルド環境など帯域と安定性を取りに行きやすく、スマホは移動中の短時間チェックや通知系で省電力が優先されがちです。どちらも同じノード名を持っていても、TUN を切る・DNS の enhanced-mode を弱める・モバイル通信時だけ軽いポリシーに落とす、といった差は Profile を分けた方が説明しやすいです。

「共用の骨格」と「端末専用の薄い差分」を分けると、片側だけ不具合が出たときの切り分けが速くなります。クライアントの選定は 用途に合う Clash クライアントの選び方 を先に読み、プロファイル切替 UI や ドラッグ＆ドロップでの購読取り込み、外部コントローラの要否を決めると迷いが減ります。

観点 ノートPC スマホ
モード TUN／システムプロキシを含め、開発ツールまで巻き込みやすい 省電力・常時接続制限・Wi-Fiとモバイルの切替が頻繁
DNS fake-ip とブラウザ DoH が衝突しやすい。学内DNSとの切替に注意 OS のプライベートDNSと二重化しやすい。失敗時は一時無効化で切り分け
ルール 研究用データセットや大容量DLを含め、帯域選びが重要 遅延耐性の低い通話より、待機電力と再接続のしやすさが重要になりやすい

Profile を分割する単位（在宅／学内／モバイル）

現実的な分割は次の三つに集約されがちです。在宅Wi-Fi（ルータ配下でプリンタやNASがある）、学内／キャンパス（SSID かゲートウェイが変わる）、外出先モバイル（電波品質と課金が制約）。SSID を信頼できるクライアントが自動検知できるなら運用は楽になりますが、Clash 単体で「今キャンパスにいる」と100%判定するのは難しいので、手動プロファイル切替を併用する前提が堅いです。

たとえば profile-campus.yaml では大学ドメインと学内ネットの RFC1918 をルール先頭へ集約し、profile-home.yaml では DOMAIN-SUFFIX でプリンタやNASを DIRECT に固定、profile-mobile.yaml では TUN を避けて mixed-port のみ、といった具合です。同じ購読でも、プロバイダ側の「同時接続数」制限に当たりやすい時間帯は、PC とスマホの自動選択グループが同じノードを叩かないよう、別の url-test 間隔 や ノード集合の分離 を検討してください。

分流ルールの骨格：先に DIRECT、後で学習トラフィック

GeoSite や rule-providers を購読末尾で一括利用する構成は便利ですが、学内ドメインが一般カテゴリに紛れると、意図せず迂回側へ抜けます。対策はシンプルで、自分の大学・寮・図書館のドメインと IP 帯を明示ルールとして先頭に置くことです。続けて、動画CDN、協働ツール、Git ホスティング、論文サイトを束ねるポリシーグループへ流し、最後に購読側のデフォルトへフォールバックする、という階層にします。

GEOSITE や GEOIP の更新が変わると末端のマッチが揺れるので、学習に直結するドメインは 自分のリスト にも複写しておくと安心です。中国語圏向けの直進ルール設計の感覚は GeoIP／GeoSite 更新の記事 と近く、更新後に一瞬だけ講義が止まる系の不具合の予防にもつながります。

ルール断片の例（教育用・実環境では置き換え）

次の YAML 断片は構造理解用です。ドメインと IP は架空か一般例です。自組織のポリシーと法令に従い、許可されたネットワークでのみ検証してください。キーや prepend 相当の有無は、使用中のコア版に合わせて読み替えます。

rules excerpt — illustrative only 
# Highest priority: keep campus & intranet on DIRECT (replace domains)
rules:
  - DOMAIN-SUFFIX,campus.example.edu,DIRECT
  - DOMAIN-SUFFIX,library.example.edu,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT

  # Lecture / collaboration stacks → explicit policy group
  - GEOSITE, youtube, Study-Proxy
  - GEOSITE, google, Study-Proxy

  # Fallback from provider bundle
  - MATCH, Proxy
⚠ 注意：上記はあくまで例です。実際の学内ドメインは入学案内や IT ヘルプの文書を参照し、許可のないスキャンや設定変更は行わないでください。

DNS・TUN と学内認証の注意点

dns.enhanced-mode を fake-ip に寄せた構成は、迂回の体験を滑らかにしますが、学内証明書や Split DNS を伴うフローでは意図しないリゾルバへ抜けると即座に壊れます。ブラウザの Secure DNS、OS の「プライベートDNS」、別VPNのDNSフックと二重化していないかを先に確認してください。レイヤの整理は TUN モードの深掘り と併読すると、トラフィックがどこを通ったか説明しやすくなります。

TUN を有効にすると、IDE やコンテナ、WSL が予想外にトンネル側へ寄ることがあります。研究用の仮想環境でだけ直結したい場合は、プロセス／CIDR ベースの例外を上流に追加するか、講義中だけ TUN を切る Profile に切り替えるのが現実的です。どちらの方針も、最終的にロードされた設定のエクスポートとログ突き合わせができるクライアントを選ぶと授業中の切り分けが速くなります。

Clash Verge Rev と Clash Meta への当てはめ

macOS や Windows では Clash Verge Rev のように、購読取り込みから TUNトグル、プロファイル切替までが一画面に収まる GUI が学習用途に向きやすいです。初手の導線は macOS セットアップ や Windows 向けの同系記事を参照してください。コア側は Clash Meta（Mihomo） へ寄せておくと、rule-provider や mixin 周りの資料が追いやすく、数年単位で見た学習コストを下げられます。

「GUI で触ったつもりが、実際にdisk上の YAML が変わっていない」ケースは初心者でも起きます。最終ロード設定のプレビューが用意されているクライアントを選び、変更後に必ず接続ログへヒットしたルール行を確認する癖を付けると、試験週間のトラブルを避けやすいです。

運用：購読更新とルール競合を避ける

  1. prepend／先頭直書き の学内例外が、購読更新後も先頭に残っているかを月1回でも確認する。
  2. 自動選択グループ の url-test 間隔を端末ごとにずらし、同じ脆弱ノードを同時に叩かない。
  3. ログレベル を一時的に上げ、講義30分前に接続試験を済ませる（本番中のログ嵐は避ける）。
  4. mixin で人間の手作業を購読本体から切り離し、更新で消えない場所に差分を置く（併合の具体的な形は mixin の記事）。

よくある質問

同じ購読をPCとスマホで使ってよい？

契約上の同時接続と利用規約を最優先してください。接続上限に達すると両方が不安定になるので、手動プロファイルで片方を低速ノードから外す、自動選択で異なる集合を使う、など競合を避ける運用を組み込みましょう。

キャンパスWi-Fiだけ直結に寄せたい

SSID で判定できるクライアント/OS 機能と組み合わせるか、キャンパス入館時にだけ「学内 Profile」へ切り替える運用が現実的です。PAC ファイル配布や学内プロキシがある場合は、ブラウザだけ学内設定に切り替える二重管理になりがちなので、どちらを正にするかを紙に書いておくと混乱が減ります。

Zoom／Teams はプロキシすべき？

地域・回線・大学のポリシーで最適解が変わります。遅延重視なら DIRECT、到達性が悪い日だけ迂回に寄せる、の二段が無難です。授業本番直前にルールを大きく変えないことも、安定運用のコツです。

まとめ

留学シナリオでは、共有購読でコストと更新負担を抑えつつ、Profile と 分流ルール で学内直結と学習向け迂回を共存させるのが Clash 系の強みです。要点は「学内らしき宛先とローカル帯域をルール前方に固定する」「DNS と TUN が認証フローを壊さないか定期点検する」「端末ごとの省電力と帯域要求を分ける」——この三つに尽きます。併せて、利用規約と法令を守り、許可された環境でのみ検証してください。

ワンタップ型の商用クライアントは手軽ですが、講義・文献・学内認証という複合シナリオでは「どのドメインがどのタイミングで DIRECT になるべきか」を自分の手で説明できないと、試験週に詰まりがちです。設定がブラックボックスのままだと、図書館プロキシや SSO の軽い挙動変化だけで数日を失うこともあります。一方、Clash V.CORE を入口に据えると、ルールログと実際のYAMLを突き合わせながら Clash Meta や Clash Verge Rev のようなオープンエコシステムへ段階的に移行しやすく、更新頻度の高い購読とも長期で付き合えます。学習に集中したい方は、公式導線から入手できるビルドをベースに、まずは「学内 DIRECT 固定＋講義CDNだけ迂回」という小さな Profile から試し、ログでヒット行を確認しながら広げていくのが安全です。Clash を公式サイトから入手し、自分のキャンパス要件に合わせてチューニングしてみてください。