研究者のためのClash分流設計

論文検索、文献管理、共同執筆を一つのパソコンで行う研究者にとって、ネットワーク設定は単なる「海外サイトを開くためのスイッチ」ではありません。Zoteroで文献情報やPDFを取得し、arXivや出版社のサイトで論文を探し、Overleafで共同執筆を続けるには、サービスごとに異なる通信先と接続特性を意識する必要があります。ブラウザだけをプロキシに通していると、論文ページは表示できてもZoteroの同期だけが失敗したり、Overleafの編集画面は開くのに画像やGit連携が止まったりすることがあります。

本稿では、研究者向けのClash設定を「すべてをプロキシへ送る」方式ではなく、学術サービスだけを適切に分流し、大学・研究機関の国内サービスと日常サイトはできるだけDIRECTにする考え方で整理します。対象はClash Verge RevやMihomo Partyなど、Mihomo系コアを利用できるクライアントです。画面の名称はクライアントのバージョンによって多少異なりますが、プロファイル、ルール、プロキシグループ、接続ログという基本構造は共通しています。

利用上の注意：大学、研究機関、出版社、学会の利用規約と所属機関の情報セキュリティ方針を優先してください。購読契約で提供される論文や個人情報を第三者へ転送しないこと、認証情報や購読URLを共有しないことも重要です。

Zotero・arXiv・Overleafの通信を分けて考える

学術ワークフローでは、サービス名が同じでも通信の目的が異なります。たとえばZoteroは論文ページを表示するブラウザとは別に、文献データベースの同期、添付ファイルの転送、WebDAVやZotero Storageへの接続を行います。ブラウザで出版社サイトが開けるからといって、Zoteroの同期も同じ経路を使っているとは限りません。デスクトップアプリがシステムプロキシを認識しない場合は、TUNまたはアプリ側のプロキシ設定が必要になります。

  • Zotero：文献情報の取得、アカウント認証、ライブラリ同期、PDFや添付ファイルのアップロード・ダウンロードを分けて確認します。同期先がZotero StorageではなくWebDAVの場合、所属機関や契約先のドメインも接続ログに現れます。
  • arXiv：arxiv.orgの論文ページ、PDF配信、検索画面、API利用では通信の形が異なることがあります。論文ページだけを確認せず、PDFを保存するところまで試してください。
  • Overleaf：ログイン、プロジェクト編集、画像・フォント・コンパイル関連のリソース取得、Git連携などが関係します。WebSocketや長めのHTTPS通信が不安定な場合、ページが開いても編集操作が遅延することがあります。
  • 大学・研究機関：学内ポータル、図書館データベース、VPN、学認、電子ジャーナルの認証ページは国内または所属機関向けの経路が前提の場合があります。これらを無条件に海外プロキシへ送ると、認証ループやアクセス拒否が起きることがあります。

最初から大量のドメインを手作業で登録するより、実際に操作してClashの接続一覧を確認する方が確実です。Zoteroで同期を実行した直後、arXivでPDFを開いた直後、Overleafでコンパイルした直後に新しい接続を確認し、ホスト名、通信結果、選択されたグループを記録します。サービスの構成は変更されるため、古いブログに掲載されたドメイン一覧をそのまま信用しないでください。

研究用プロファイルの基本構成

研究用途では、日常の動画やショッピングまで海外ノードへ送る必要はありません。通信量を抑え、大学サイトやローカルネットワークの安定性を保つため、研究サービス専用のプロキシグループを作ると管理しやすくなります。グループ名は、たとえばACADEMIC、RESEARCH、DIRECTのように役割が分かるものにします。自動選択だけに任せるのではなく、論文検索や共同執筆で安定したノードを手動で固定できるようにしておくと、長時間の作業中に経路が変わる問題を減らせます。

ルールの順序は非常に重要です。一般的には、ローカルネットワーク、大学や研究機関の例外、研究サービス、プライバシー保護用のルール、地域別ルール、最後のFINALという順番で評価します。広いGEOIPルールやMATCHを上位に置くと、arXivやOverleaf向けの指定より先に処理され、意図したグループへ到達しません。

proxy-groups:
  - name: ACADEMIC
    type: select
    proxies:
      - Research-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,arxiv.org,ACADEMIC
  - DOMAIN-SUFFIX,overleaf.com,ACADEMIC
  - DOMAIN-SUFFIX,zotero.org,ACADEMIC
  - DOMAIN-SUFFIX,edu,DIRECT
  - GEOIP,PRIVATE,DIRECT
  - MATCH,DIRECT

これは出発点にすぎません。eduドメインだから必ず国内とは限らず、大学サービスが外部CDNや認証基盤を利用している場合もあります。また、ZoteroのPDF保存先やOverleafの補助リソースは、代表ドメイン以外へ接続することがあります。接続ログで確認したホストだけを、必要な範囲で追加してください。ワイルドカードを広く設定しすぎると、研究とは無関係な通信まで同じグループへ流れてしまいます。

設定変更の注意：ルールを追加する前にプロファイルを複製し、元の設定を保存してください。研究作業中に全体設定を変更すると、認証セッションやアップロードが途中で切れる可能性があります。

実際に設定して接続を確認する手順

ここでは、現在使っているClashクライアントに研究用の分流を追加する流れを示します。特定のUI名に依存しないよう、どのクライアントでも見つけやすい項目を基準にしています。作業前にZoteroの同期状態を確認し、Overleafのプロジェクトを保存しておくと、設定変更による影響を切り分けやすくなります。

  1. プロファイルをバックアップ：現在使用中のYAML、購読URL、手動で追加したルールを保存します。購読URLには認証情報が含まれる場合があるため、公開リポジトリや共有フォルダーには置かないでください。
  2. 研究用プロキシグループを作成：ACADEMICなどのselectグループを追加し、安定性を確認したノードとDIRECTを登録します。最初は自動切り替えより手動選択の方が検証しやすくなります。
  3. 代表ドメインを登録：arxiv.org、overleaf.com、zotero.orgを必要に応じて追加します。サブドメインの扱いを確認し、単一ホストだけならDOMAIN、配下全体ならDOMAIN-SUFFIXを使います。
  4. 大学サービスを先に除外：学内ポータル、図書館、学認、VPN、プリンターやNASなどのローカル宛先をDIRECTにします。GEOIP,PRIVATE,DIRECTだけで足りない場合は、所属機関のドメインを明示してください。
  5. 設定を検証して再読み込み：クライアントの設定チェック機能を実行し、YAMLのインデントとグループ名の綴りを確認します。エラーがなければプロファイルを再読み込みし、接続一覧を開いたままテストします。
  6. サービスごとに確認：arXivで検索とPDF表示、Zoteroで文献取得と同期、Overleafでログイン・編集・コンパイルを順番に行います。各通信が想定したグループへ入り、失敗時のホスト名が記録されているか確認します。

検証では「ページが開いたか」だけで合否を決めないでください。Zoteroなら新しい文献情報が正しく保存され、添付PDFが同期されることまで確認します。Overleafならプロジェクトの編集、画像の表示、コンパイルログ、PDFプレビューを一通り見ます。arXivもHTMLページとPDFの両方を試し、片方だけが失敗していないか確認します。接続一覧に同じホストが複数回現れる場合は、通信先ごとのルールを分ける必要があるかもしれません。

DNS・TUN・端末アプリの切り分け

ドメインルールが正しいのに動作が不安定な場合、DNS解決の経路を確認します。OSやブラウザがClashの外側で名前解決すると、実際の接続先とルール判定の前提がずれることがあります。TUNモードを使う場合は、Clash側のDNS、fake-ipまたはredir-hostの方式、大学VPNとの併用、ローカルネットワークの除外を一つずつ確認してください。TUNを有効にした直後に学内プリンターやNASへ届かなくなった場合は、まずプライベートアドレスと学内サブネットをDIRECTへ戻します。

Zoteroのようなデスクトップアプリは、システムプロキシを利用する版と、独自のネットワーク処理を行う版があります。ブラウザは通るのにZoteroだけ失敗する場合、接続一覧にZotero関連の通信が出ているかを確認し、出ていなければHTTP混合ポートの設定、アプリ側のプロキシ項目、またはTUNを検討します。反対に、TUNを使っているのに認証だけ失敗する場合は、認証ポータルや大学VPNがプロキシを想定していない可能性があります。

  • arXivのPDFだけ失敗：ページ用ホストとPDF配信用ホストが異なる可能性があります。PDFを開いた瞬間の接続ログを記録します。
  • Zotero同期が保留のまま：アカウント認証、同期API、添付ファイル保存先を分けて確認し、同期を何度も繰り返す前にログを保存します。
  • Overleafの編集が切れる：ノードの自動切り替えを停止し、長時間接続に向く安定したノードを選びます。ブラウザの拡張機能や企業ネットワークの検査も確認します。
  • 大学サイトだけ開けない：大学ドメイン、学認、VPN、DNSの順に確認し、研究用プロキシへ無条件に送るルールを一時的に外します。

研究を止めないための運用ルール

研究用のClash設定は、一度作って終わりではありません。購読更新やクライアント更新の後には、代表的な三つの作業を短時間で再確認する習慣を作ると安全です。まずarXivで新しい論文の検索とPDF表示を試し、次にZoteroでテスト文献を取得して同期し、最後にOverleafで小さな変更を保存してコンパイルします。これらを毎回同じ順序で行えば、どの更新後に問題が発生したのか追跡しやすくなります。

設定ファイルには、ルールの目的と追加理由を英語のコメントで残しておくと、後から見直すときに便利です。たとえば、あるホストを追加した日付、接続ログで確認したサービス、DIRECTでは失敗したためACADEMICへ移した理由などを記録します。不要になったルールは定期的に削除し、同じドメインを複数のルールで重複指定しないようにします。購読プロファイルが自動更新で上書きされる環境では、手動ルールを別のoverrideやルールプロバイダに分離しておくと、更新時の消失を防ぎやすくなります。

また、ノードの速さだけで研究用経路を選ばないことも大切です。論文PDFの取得では瞬間的な速度より、長時間の安定性、TLS接続の継続、頻繁なIP変更が起きないことが重要です。Overleafの共同編集やコンパイルでは遅延の小ささと切断の少なさを優先し、Zoteroの大量同期では帯域と再試行の挙動を見ます。サービスごとに最適なノードが異なる場合は、ACADEMICグループを分けることも検討できます。

無料のブラウザ拡張や単純な全体VPNは導入が簡単な反面、Zoteroのデスクトップ同期、大学内サービス、Overleafの長時間通信を個別に制御しにくく、設定の理由を確認できるログも限られます。一方、Clash 公式サイトはMihomo系クライアントの導入先とプロファイルの考え方を整理し、ドメイン分流、TUN、DNS、端末アプリの切り分けを同じ流れで確認できる点が実務向きです。研究サービスだけを安定した経路へ送り、国内の大学サイトはDIRECTに戻したい方は、まずClash 公式サイトをダウンロードして、このガイドの手順を自分の接続ログに合わせて試してみてください。