研究者向けClash設定術：Google Scholarと論文サイトを快適に使う

文献調査では、検索結果が表示されない、論文PDFの取得が途中で止まる、出版社のページだけタイムアウトするといった小さな障害が積み重なり、研究の流れが大きく中断されます。Google Scholar、arXiv、IEEE Xplore、出版社の電子ジャーナルは、同じ「論文サイト」でも利用するドメインや通信方式が異なるため、すべての通信を一律にプロキシへ送るだけでは安定しません。この記事では、研究者の利用場面に合わせてClashのルールを設計し、検索・HTML本文・PDF・引用情報を必要に応じて適切な経路へ振り分ける方法を解説します。

研究者向けにClashを設計する理由

論文サイトを使うとき、最初に確認したいのは「どのサービスをプロキシするか」ではなく、「どの処理を安定させたいか」です。Google Scholarの検索画面だけを閲覧する場合と、arXivから大容量PDFを連続してダウンロードする場合では、必要なルールも最適なノードも異なります。

たとえば検索結果は表示されるのに、結果ページ内のPDFリンクだけが開けないことがあります。これはGoogle Scholar本体と、論文をホストしている大学リポジトリ、出版社、研究機関のドメインが別々だからです。また、PDFを取得できても、認証ページやCAPTCHAが表示される場合は、同じ出口IPを短時間に多くの接続が共有している可能性があります。Clashの設定だけでサービス側の制限を回避できるわけではありませんが、経路の一貫性を保ち、不要な再試行を減らすことはできます。

対象ドメインとルールの考え方

Clashではドメインベースのルールを中心に構成すると、DNS解決後のIPアドレスが変わっても意図した経路を維持しやすくなります。特にCDNを利用する出版社や、複数のサブドメインを持つ大学リポジトリでは、固定IPを手書きするよりも DOMAIN-SUFFIX を使う方が管理しやすいでしょう。

Google Scholarだけを対象にする場合は scholar.google.com を明示すれば十分ですが、引用エクスポートや検索結果のリンク先まで安定させたい場合は、実際の接続ログを確認しながら対象を追加します。arXivでは通常の閲覧用ドメインだけでなく、PDF配信やエクスポートで別のホスト名が使われることがあります。IEEE Xploreや出版社サイトでも、本文、画像、認証、静的ファイルが異なるドメインへ分散しているため、一度にすべてを推測するより、失敗した接続をログから特定する方が確実です。

基本設定とルール記述

以下はMihomo系クライアントで利用しやすい最小構成の例です。プロキシグループ名は自分の設定に合わせて変更してください。既存の設定に追加する場合は、同じキーを重複させず、既存の rules の上部へ学術サイト用ルールを挿入します。

proxy-groups:
  - name: Academic
    type: select
    proxies:
      - Auto-Select
      - DIRECT

rules:
  - DOMAIN,scholar.google.com,Academic
  - DOMAIN-SUFFIX,arxiv.org,Academic
  - DOMAIN-SUFFIX,ieeexplore.ieee.org,Academic
  - DOMAIN,doi.org,Academic
  - DOMAIN-SUFFIX,crossref.org,Academic
  - MATCH,Final

ルールの順番は非常に重要です。Clashは上から順に評価するため、学術ドメインより先に広い GEOIP、IP-CIDR、または別の大規模ルールセットがあると、意図した Academic グループへ到達しない場合があります。学術サイトのルールは、一般的な地域判定や最終ルールより前に置いてください。

DIRECT を候補に残しておくと、所属機関のネットワークや国内回線で直接アクセスした方が速い場合に手動で切り替えられます。一方、検索画面は直接、PDFだけはプロキシという細かな分割は、サイトのリダイレクト構造によってログイン状態が不安定になることがあります。まずは同一サービスを同じグループへ送り、問題が再現する場合だけ分割するのが安全です。

実際に設定して動作を確認する手順

設定を変更したら、いきなり大量の論文をダウンロードするのではなく、少数の代表的な通信で確認します。Clash Verge、Clash Verge Rev、Mihomoのダッシュボードでは、接続先、適用ルール、使用中のプロキシグループを確認できます。

1. 設定ファイルをバックアップし、学術サイト用のプロキシグループを作成します。
2. Google Scholarで一般的なキーワードを検索し、検索結果、引用情報、関連論文のリンクを順に開きます。
3. arXivで論文概要、HTML版、PDF版をそれぞれ開き、接続ログに異常な再試行がないか確認します。
4. IEEE Xploreまたは出版社サイトで、検索、論文詳細、DOIリンク、PDFリンクの経路を確認します。
5. ダッシュボードの接続一覧で、対象ドメインが Academic にマッチしていることを確認します。
6. 同じ操作を別のノードでも行い、速度だけでなくタイムアウト、認証状態、PDFの完全性を比較します。

PDFのダウンロードでは、ブラウザの表示に成功したかだけでなく、ファイルサイズと末尾まで開けるかを確認してください。途中で切断されたPDFは、ブラウザ上では一見正常に見えても、保存後に破損していることがあります。大容量ファイルだけ失敗する場合は、ノードの帯域、接続維持時間、HTTP/2やQUICの相性を疑います。複数ノードを登録した url-test グループを使う場合も、単純なレイテンシが低いノードが必ずしもPDF取得に最適とは限りません。

rules:
  # 学術サイトの具体的なルールを先に置く
  - DOMAIN,scholar.google.com,Academic
  - DOMAIN-SUFFIX,arxiv.org,Academic
  - DOMAIN-SUFFIX,ieeexplore.ieee.org,Academic
  - DOMAIN-SUFFIX,doi.org,Academic

  # 所属機関の内部サービスは必要に応じて直接接続
  - DOMAIN-SUFFIX,library.example.edu,DIRECT

  # 最終ルール
  - MATCH,Final

DNSと認証で起きやすい問題

学術サイトだけ接続できない場合、ルールの誤りだけでなくDNS処理も確認します。fake-ipを利用している環境では、まれに認証システムや古いPDFビューアーが仮想IPへの接続を正しく処理できないことがあります。その場合は対象ドメインを fake-ip-filter に追加し、実IPで解決して挙動を比較します。ただし、除外を増やしすぎるとDNSリークやルール判定の不整合につながるため、問題が再現するドメインだけを対象にしてください。

ログイン状態が頻繁に失われる場合は、Google Scholar本体、出版社の認証ドメイン、所属機関のリモートアクセス用ドメインが異なる経路を通っていないか確認します。認証Cookieはドメインやブラウザのポリシーに依存するため、Clashで経路を変えただけでは解決しないこともあります。ブラウザのプライベートウィンドウで再現性を確認し、拡張機能、Cookie、機関VPN、プロキシを一度に変更しないことが切り分けのコツです。

また、システム全体をTUNモードで処理している場合、ブラウザだけでなく文献管理ソフト、PDFビューアー、CLIの curl や論文取得ツールも同じルールの影響を受けます。ブラウザで成功しても、文献管理ソフトのメタデータ取得が失敗するなら、接続先のAPIドメインをログから確認して追加します。

安定運用のための改善ポイント

研究用途では、速度の最大値よりも再現性が重要です。ノードを頻繁に自動切り替えすると、ログインセッション、出版社側のリスク判定、ダウンロード接続が不安定になることがあります。学術サイト用には、比較的安定したノードを選べる select グループを用意し、通常利用では固定しておくとトラブルを減らせます。障害時だけ別ノードへ切り替え、復旧後に元へ戻す運用が現実的です。

• ルールは広げすぎず、接続ログで確認したドメインから追加する。
• 検索、認証、PDF配信を異なる経路へ無理に分割しない。
• 設定変更前にYAMLを保存し、変更後は構文エラーを確認する。
• 同じ論文を何度も再試行せず、ノード・DNS・ブラウザを一つずつ切り分ける。
• Rule Providerを使う場合は、学術サイト用ルールの更新元と更新間隔を確認する。
• 所属機関のVPNや学認を利用する場合は、機関の公式手順を優先する。

Rule Providerで学術ドメインを管理する場合でも、公開リストを無条件に信頼するのは避けてください。リストに含まれるドメインが多すぎると、研究とは無関係な通信までプロキシされ、速度やプライバシーに影響します。自分の研究分野で常用するサービスを小さなリストとして管理し、数週間ごとに接続ログと実際の利用状況を見直す方が、長期的にはメンテナンスしやすい方法です。

よくある質問

Google Scholarだけをプロキシすれば十分ですか？

検索結果の表示だけなら十分な場合があります。しかし、リンク先の出版社、大学リポジトリ、arXiv、DOI転送先は別ドメインです。PDFや引用情報まで安定させたい場合は、接続ログを確認して必要なドメインを学術用グループへ追加してください。

arXivのPDFだけがダウンロードできない場合はどうしますか？

まず同じノードで概要ページとPDFを比較し、接続ログにタイムアウトやリセットがないか確認します。次に別ノードで再試行し、DNS、TUNモード、ブラウザ拡張機能を一つずつ切り分けます。大量の再試行は避けてください。

IEEEや出版社サイトでCAPTCHAが表示されます。

CAPTCHAは出口IPの評価、アクセス頻度、Cookie、ブラウザ環境など複数の要因で表示されます。Clashのルールを増やすだけでは改善しないことがあります。アクセス頻度を下げ、安定したノードを使い、所属機関の正規アクセス方法がある場合はそれを利用してください。

DIRECTとプロキシはどちらを選ぶべきですか？

環境によって異なります。直接アクセスで安定するサービスはDIRECT、接続拒否やタイムアウトが発生するサービスはプロキシを選びます。学術用グループに両方を登録しておけば、サイトごとに動作を比較しながら最適な経路を判断できます。

研究環境のClash設定は、すべての通信を強制的にプロキシすることではなく、文献検索からPDF取得までの経路を観察し、必要な通信だけを安定させることが目的です。Google Scholar、arXiv、IEEE Xplore、出版社サイトを個別に検証し、ルール、DNS、ノードを小さく調整していけば、検索の中断や論文取得の失敗を大幅に減らせます。設定を保存して再利用できる形に整え、研究テーマや所属機関の環境が変わったときだけ見直す運用をおすすめします。