研究者向けClash設定術｜Google ScholarとZoteroを快適化

研究者向けClash設定の考え方:検索・取得・管理を分けて考える

Google Scholar、arXiv、Zotero、Overleafは、研究活動の中で同じ日に何度も使うサービスです。しかし、これらをすべて同じプロキシ経路へ送ればよいとは限りません。論文検索は検索結果の表示速度が重要で、PDF取得では対象サイトごとの接続安定性が問題になり、Zoteroはメタデータ取得・添付ファイル保存・同期という複数の通信を行います。Overleafもブラウザ表示だけでなく、ログイン、プロジェクト編集、コンパイル結果の取得などが関係します。

Clashでは、通信をドメインやIPアドレス、プロセス名などの条件で判定し、最初に一致したルールの出口へ送ります。そのため、研究用途では「学術サイトはすべてPROXY」という単純な構成よりも、例外を先に定義し、対象ドメインをまとめてプロキシグループへ送る構成のほうが管理しやすくなります。国内のミラーや所属機関のサービスはDIRECT、海外の論文データベースや取得元はPROXYというように、目的別に分けるのが基本です。

ここでいうPROXYは特定のノード名ではなく、複数のノードをまとめた策略グループを想定しています。ノードを直接ルールに書くと、契約中のノード名を変更したときに設定全体を修正しなければなりません。selectやurl-testなどのグループを用意し、ルール側は常にグループ名を参照すると、論文執筆中の切り替えも安全に行えます。

Google Scholarと学術サイトの振り分け

Google Scholarは検索ページだけでなく、検索結果から遷移する出版社サイト、大学リポジトリ、データベース、PDF配布サーバーへ接続します。Scholar本体だけをルールに追加しても、リンク先が別ドメインなら同じ経路にならないことがあります。検索結果は表示できるのに、PDFリンクをクリックするとタイムアウトする場合は、リンク先のドメインがDIRECTや誤ったグループに入っていないかを確認します。

arXivでは論文ページとPDFのホスト名が分かれることがあります。一般的なドメイン指定に加えて、実際のブラウザ開発者ツールやClashの接続ログで、どのホストへ接続しているかを確認してください。DOIリンクも最終的には出版社や機関リポジトリへリダイレクトされるため、最初のURLだけを見て判断しないことが大切です。

mihomoでドメイン分類データを利用できる環境なら、学術サイトを個別に増やす前に明確なドメインルールを置きます。学術サービスのドメインは分類データにすべて含まれるとは限らないため、重要な出版社やリポジトリはDOMAIN-SUFFIXで個別指定します。短い文字列に反応するDOMAIN-KEYWORDは誤爆しやすく、研究用設定の中心には向きません。

Zotero設定:メタデータ取得とPDF同期を安定させる

Zoteroの通信は、ブラウザで論文を保存するときのコネクター、識別子から書誌情報を取得するときのAPI、添付PDFをダウンロードするときの出版社サーバー、さらにクラウド同期に分かれます。Zotero本体だけをプロキシに送る方法は、デスクトップ環境では有効な場合がありますが、ブラウザから保存したリクエストやOSの名前解決まで自動的に同じ扱いになるとは限りません。

まずZoteroの設定で同期を有効にする前に、ブラウザで対象論文ページを開き、コネクターが正しく書誌情報を認識できるか確認します。タイトル、著者、雑誌名、発行年、DOIが取得できても、PDFの添付だけ失敗する場合があります。その場合はZoteroの問題ではなく、出版社のPDFホスト、認証リダイレクト、Cookie、あるいは接続経路の問題である可能性が高いです。

1. Zoteroとブラウザを終了し、Clashの現在のプロファイルをバックアップします。既存の設定を直接書き換える前に、復元可能な状態を残します。
2. ブラウザでGoogle Scholarまたは出版社の論文ページを開き、Clashの接続ログに表示されるドメインを記録します。PDF取得時に追加されるホストも別に確認します。
3. 確認した出版社、リポジトリ、同期関連のドメインを、必要な範囲だけDOMAIN-SUFFIXでPROXYグループへ送ります。
4. Zoteroで書誌情報を保存し、PDF添付、ファイル閲覧、同期の順にテストします。一度に全機能を試すと、どの段階で失敗したか分からなくなります。
5. 同期が終わった後、別端末でタイトル、添付ファイル、コレクション構造が確認できるかをチェックします。同期済みに見えても、添付ファイルだけ保留になっている場合があります。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - "研究ノードA"
      - "研究ノードB"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,scholar.google.com,PROXY
  - DOMAIN-SUFFIX,arxiv.org,PROXY
  - DOMAIN-SUFFIX,overleaf.com,PROXY
  - DOMAIN-SUFFIX,example-university.edu,DIRECT
  - MATCH,DIRECT

上のexample-university.eduは説明用の明らかな例です。実際には所属機関から案内されたドメインへ置き換えてください。学術サービスのドメインを必要以上に広げたり、認証情報を含むURLを設定ファイルへ貼り付けたりするのは避けます。Zoteroの同期をプロキシ経由にする場合も、アカウント情報やアクセストークンをログや共有設定へ残さないよう注意してください。

DNSとTUNを調整してPDF取得の失敗を減らす

研究用途で「検索はできるがPDFだけ開かない」という問題が起きるとき、ルールだけでなくDNSも確認します。ブラウザやZoteroが出版社のホスト名をローカルDNSで解決し、その結果をDIRECT接続へ渡していると、Clashの想定したプロキシ経路から外れることがあります。特に複数のDNSアプリ、VPN、ブラウザ内蔵DoHが同時に有効な環境では、同じドメインでも解決結果や経路が変わります。

mihomoでは、端末全体を扱いたいときにTUNを利用できます。TUNは仮想ネットワークインターフェースを通じて、システムプロキシに対応していないアプリの通信もClashへ取り込む仕組みです。Windowsでは管理者権限やサービスモード、macOSではネットワーク拡張やヘルパーの許可が必要になることがあります。許可を出しただけで終わらず、接続ログにZoteroの通信が現れることを確認してください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://example-dns.invalid/dns-query
  proxy-server-nameserver:
    - 223.5.5.5

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

fake-ipを使う場合、古いアプリやIPアドレスを直接参照するアプリで接続できなくなることがあります。Zoteroの同期やブラウザの表示に異常が出たら、まずDNSキャッシュを消去し、ClashのDNSログと接続ログを確認します。TUNをオンにしたまま別のVPNを重ねると、ルーティングの優先順位が競合して通信が不安定になるため、検証時はClash以外のトンネルを停止してください。

研究作業を止めないための切り分け手順

問題が起きたときは、ノードを何度も切り替える前に、検索、論文ページ、PDF、Zotero保存、同期という5段階へ分けて確認します。検索ページだけが失敗するなら検索ドメインまたはDNS、PDFだけが失敗するなら出版社の配信ホストまたはリダイレクト、Zotero保存だけが失敗するならコネクターとブラウザ権限を疑います。

ルールを追加した後は、Clashの接続履歴で実際の策略グループを確認します。設定ファイルにルールが存在していても、上にある広すぎるGEOIPやMATCHが先に一致すれば、そのルールには到達しません。研究用ドメインを追加するときは、既存のMATCHより前に置き、再読み込み後に新しい接続を発生させてください。

ノードの速度だけでなく、TLS接続の安定性、長時間接続、ファイル転送の継続性も確認します。Overleafの編集や大きなPDFの取得では、短時間の速度テストより接続が切れないことのほうが重要です。複数ノードを用意し、通常利用向けと長時間作業向けを分けると、ノード障害時にも作業を再開しやすくなります。

よくある質問