研究者向けClash設定：Google Scholar・Zotero・Overleaf活用術

研究者の通信環境でClashが役立つ場面

研究者の作業は、一般的なウェブ閲覧よりも複数のサービスを短時間に行き来する点に特徴があります。Google Scholarで論文を検索し、出版社の電子ジャーナルで本文を確認し、DOIやメタデータをZoteroへ取り込み、最後にOverleafで原稿と参考文献を共同編集する、という流れは珍しくありません。ところが、これらのサービスは同じドメインだけで完結しません。検索結果から出版社、認証基盤、PDF配信 CDN、CAPTCHA、クラウドストレージまで接続先が広がるため、ひとつのサイトだけを開ければ十分とは限りません。

Clashを研究用途で使う場合の要点は、すべての通信を無条件にプロキシへ送ることではありません。大学の学内システム、研究室のファイルサーバー、国内の機関リポジトリはDIRECTにし、Google Scholarや海外出版社など、接続が不安定になりやすいサービスだけを安定したプロキシグループへ送ります。このように用途単位で経路を分けると、論文検索の速度と学内サービスへの到達性を両立しやすくなります。

Google Scholarと学術データベースを分流する

Google Scholarでは検索ページそのものに加えて、検索結果から出版社の論文ページ、DOIサービス、大学リポジトリ、論文共有基盤へ遷移します。検索画面だけをルールに登録しても、リンク先でタイムアウトが起きれば研究作業は止まります。まずClashの接続ログを開き、検索、結果クリック、PDF表示という三つの操作を別々に行い、実際に現れたホスト名を記録してください。推測で大量のドメインを登録するより、観測した接続を少しずつルールへ追加する方が保守しやすい方法です。

Googleの各サービスをひとつのグループにまとめる方法もありますが、大学のメールや学内認証まで同じ出口へ送ると、ログイン状態やアクセス判定が不安定になる場合があります。研究用には、検索・論文閲覧向けのグループと、所属機関向けのDIRECTルールを分ける設計が安全です。たとえば検索で利用するドメインをDOMAIN-SUFFIXでまとめ、大学のドメインや学内 IP 範囲はそれより上位に置きます。Clashは上から順に評価するため、広いルールを先に置くと、意図した例外が機能しません。

Illustrative routing fragment — replace domains with your observed hosts

rules:
  - DOMAIN-SUFFIX,university.example,DIRECT
  - DOMAIN-SUFFIX,scholar.google.com,RESEARCH_STABLE
  - DOMAIN-SUFFIX,doi.org,RESEARCH_STABLE
  - DOMAIN-SUFFIX,overleaf.com,RESEARCH_STABLE
  - DOMAIN-SUFFIX,zotero.org,RESEARCH_STABLE
  - MATCH,YOUR_DEFAULT_POLICY

上の例はそのまま貼り付ける完成設定ではありません。購読プロファイルによってはルール名が異なり、既存のルールプロバイダが同じドメインを先に処理していることもあります。変更前に現在のYAMLを保存し、Clashのルールテスターやライブ接続で、Google Scholarの検索、出版社ページ、大学サイトの三つが期待したポリシーに入るかを確認してください。

Zoteroの文献取り込みと同期を安定させる

Zoteroでは、ブラウザのコネクターから書誌情報を取り込む処理と、デスクトップアプリがライブラリや添付ファイルを同期する処理を分けて考える必要があります。ブラウザで論文を表示できても、Zoteroの同期だけが止まることがあります。反対に、書誌情報は取り込めてもPDF添付ファイルのアップロードで失敗するケースもあります。これはブラウザとデスクトップアプリが異なるプロキシ設定や環境変数を参照しているためです。

まずZoteroのアカウント認証、ライブラリ同期、添付ファイルの同期を一度に実行せず、順番に試します。Clashの接続ログで、Zotero関連のホストがどのポリシーへ入ったか、TLS接続が途中で切れていないか、同じ操作中にDIRECTとプロキシが混在していないかを見ます。同期の途中で出口ノードが変わると、短いメタデータ通信は成功しても、大きなPDFや画像の転送だけが再試行を繰り返すことがあります。

システムプロキシを利用するGUIアプリでも、アプリ内のネットワーク実装がOS設定を完全には継承しない場合があります。その場合は、Clashのmixed-portを確認し、Zotero側でHTTPプロキシを個別指定できるかを調べます。設定を二重に行うと、アプリ内プロキシとTUNが競合することもあるため、最初はどちらか一方だけを有効にしてください。同期が成功した後にTUNを試すと、原因の切り分けが簡単になります。

Overleafで共同執筆するときの接続設計

Overleafの共同編集は、単純なページ読み込みだけでなく、ログイン、プロジェクト API、リアルタイム更新、画像やテンプレートなどの静的ファイル取得が組み合わさっています。画面は開くのに共同編集者の変更が反映されない、コンパイル結果だけ更新されない、プロジェクトへのファイルアップロードが止まる、といった症状は、それぞれ別の接続層で起きている可能性があります。

研究室で複数人が同じプロジェクトを編集する場合、全員が完全に同じノードを使う必要はありません。しかし、ログインやリアルタイム同期の途中で接続元が頻繁に変わると、セッション保護や再接続処理が不安定になることがあります。Overleaf向けのポリシーグループには、なるべく遅延よりも長時間接続の安定性を優先したノードを登録し、url-testの測定先だけで選ばないようにします。小さな速度テストが速いノードでも、長いコンパイルや大きなプロジェクト同期に弱い場合があるためです。

Overleafの通信を研究用グループへ送る一方、学内 Git サーバーや研究室の NAS はDIRECTに分けると、共同編集と内部資料の扱いを整理できます。学内サービスのドメインが広い場合は、必要なサブドメインを確認してから限定的に登録してください。DOMAIN-SUFFIXを大きく設定しすぎると、メール、管理画面、認証基盤まで意図せず同じ出口へ流れることがあります。

接続テストとルールの保守方法

設定を作ったら、機能ごとに再現手順を固定します。最初にGoogle Scholarで同じキーワードを検索し、次に出版社の本文ページを開き、Zoteroへ書誌情報を保存します。その後、Zoteroの同期を実行し、Overleafでは小さな変更を保存して別のブラウザまたは共同編集者側に反映されるか確認します。毎回異なるページを試すと原因が比較できないため、テスト用の論文、テスト用のZoteroコレクション、テスト用のOverleafプロジェクトを用意しておくと便利です。

失敗したときは、いきなりルールセット全体を入れ替えないでください。まずDNS解決、TCP接続、TLSハンドシェイク、HTTP応答、長時間接続のどこで止まったかを時間順に整理します。Clashの接続ログにタイムアウトやリセットが出ている場合は、同じ操作を別ノードで一度だけ試し、ノード品質の問題とルールの問題を分けます。別ノードで成功するならポリシーの意図は合っている可能性が高く、すべてのノードで失敗するならホスト名の不足、認証状態、サービス側の障害を確認します。

研究用設定の原則：「検索できた」だけで成功と判断せず、検索、本文取得、文献同期、共同編集という一連の作業を通して確認します。サービスごとの接続先を観測し、必要最小限のルールだけを追加し、変更前後の差分を残すことが長期運用の近道です。

研究室の環境では、購読プロファイルが自動更新されるたびにローカルルールの優先順位が変わることがあります。自分用の設定を購読本文へ直接追記するのではなく、ローカルオーバーライドや専用プロファイルとして管理し、更新後にルール名とグループ名を確認してください。学期の切り替えや所属変更で大学ドメインが変わった場合も、古いDIRECT例外を残さない方が安全です。設定ファイルは日付と用途を含む名前でバックアップし、研究データそのものとは別の安全な場所に保存します。

ブラウザ拡張だけに依存する方法は、Google Scholarの表示には手軽でも、Zoteroデスクトップ同期やOverleafの長時間接続まで一貫して扱いにくいことがあります。逆に、すべてをTUNへ送るだけの構成は学内サービスや研究室内ネットワークとの境界が曖昧になり、トラブル時の検証範囲が広がります。Clash V.COREなら、ライブ接続ログ、明示的なルール順、mixed-portとTUNの段階的な切り替えを使って、Scholar・Zotero・Overleafを用途別に観測できます。研究環境に合わせて経路を細かく整えたい方は、設定をバックアップしたうえでClash V.COREのダウンロードページから導入を始めてください。