研究者向けClash設定｜Google Scholar・arXivの論文検索を快適にする方法

研究ワークフローを整理し、必要な通信だけを振り分ける

Google Scholarで論文を探し、arXivでプレプリントを確認し、IEEE Xploreや大学図書館のサイトで本文にアクセスする。研究では、検索サービスだけでなく、認証、文献管理、共同執筆の通信も日常的に発生します。すべての通信を同じプロキシ経由にするのではなく、サービスごとに経路を分けると、接続の切り分けと学内サービスへの配慮がしやすくなります。

Clashクライアントは設定の読み込みやシステムとの連携を担い、Clashまたはmihomoカーネルが通信をルールに照合して、プロキシグループや直接接続を選びます。システムプロキシは対応するアプリの通信をコアへ渡すための設定で、TUNは仮想ネットワークインターフェースを通る通信を取り込む方式です。どちらを使っても、ルールの順序や選択中のグループが不適切なら、期待した経路にはなりません。

• 論文検索：Google Scholarの検索画面や結果ページを、既存のプロキシグループまたは直接接続へ振り分けます。
• プレプリント取得：arXivのページ、PDF、APIなど、必要なドメインをまとめて扱います。
• 文献管理・執筆：Zoteroの同期通信やOverleafの編集・保存通信を、学内ネットワークや普段の利用条件に合わせて決めます。
• 機関認証：大学のシングルサインオン、図書館ポータル、学内限定のサイトは、大学が案内する接続方法を優先します。

対象ドメインを絞り、ルールの優先順位を決める

最初からGoogle全体、大学全体、あるいはすべてのHTTPS通信をプロキシへ送る必要はありません。Google Scholarだけを対象にするなら、まずscholar.google.comを指定します。arXivはarxiv.orgのサブドメインも扱えるようサフィックスで指定し、IEEE Xploreは閲覧に必要なホストに対象を絞ります。サービスが別ドメインへ移動したり、CDNを利用したりする場合があるため、接続履歴で実際の宛先も確認してください。

以下はmihomo形式のルール例です。学術プロキシは説明用の名前なので、実際の設定に存在するプロキシグループ名へ置き換えてください。利用中のコアがmihomoでない場合は、ルール種別や拡張仕様の対応状況を先に確認します。

rules:
  # 大学の認証・学内サービスは、機関の案内に合わせて先に指定
  - DOMAIN,login.example-university.edu,DIRECT
  - DOMAIN-SUFFIX,library.example-university.edu,DIRECT

  # 学術サービスの例
  - DOMAIN,scholar.google.com,学術プロキシ
  - DOMAIN-SUFFIX,arxiv.org,学術プロキシ
  - DOMAIN,ieeexplore.ieee.org,学術プロキシ

  # 残りの通信は既存の運用方針に合わせる
  - MATCH,既定の選択グループ

example-university.eduは例示用のドメインで、そのまま使う設定ではありません。大学から指定された正確なログイン先や図書館ドメインに置き換えてください。大学のドメイン全体をDIRECTにすると、学内サイト以外の関連サービスまで直接接続になることがあります。反対に、学内サービスを広範囲にプロキシへ送ると、認証ループや接続失敗を招く場合があります。

• ルールは上から評価：具体的なホスト名や学内認証のルールを、広いサフィックスルールやMATCHより前に置きます。
• 末尾のルールに注意：MATCHより後ろに追加したルールは、通常その前にあるMATCHで通信が決まるため評価されません。
• 広いGoogle指定を避ける：DOMAIN-SUFFIX,google.comを加えると、Scholar以外のGoogleサービスにも影響します。必要な通信をログで特定してから追加します。
• ルール提供元との競合を確認：ルールセットやサブスクリプションの更新で順序が変わる構成では、クライアントのオーバーライド機能など、更新後も維持できる方法を使います。

動作中の設定を確認し、少数のルールから試す

ここでは、現在の設定を控えたうえで、ScholarとarXivの2つだけを試します。クライアントごとにメニュー名は異なります。サブスクリプションの原文を直接書き換えると更新時に変更が失われることがあるため、まずクライアントのオーバーライド、マージ、またはローカル設定機能が利用できるか確認してください。

1. クライアントの「設定」「プロファイル」などを開き、使用中のコア名とバージョン、ルールモード、選択中の設定を記録します。読み込んだだけでなく、その設定が有効になっていることも確認します。
2. 現在有効な設定のrulesと、学術通信に使うプロキシグループ名を確認します。グループが設定に存在しない場合は、ルールだけ追加せず、既存の選択グループ名を使ってください。
3. 大学の認証先と図書館サイトの正式なドメインを、大学の案内から確認します。接続履歴に表示されたホスト名も参考になりますが、ログにはアカウント名やURLの機密情報を含めないよう注意します。
4. ルール例から大学の行を実際のドメインに置き換え、ScholarとarXivのルールを追加します。既存の広いGoogleルールや末尾のMATCHより前に置きます。
5. 保存後にクライアントの設定チェックや再読み込みを実行し、エラーがないことを確認します。コアのログでYAMLの解析失敗や、存在しないグループ名に関する警告がないか調べます。
6. Scholarの検索ページとarXivの論文ページを開き、クライアントの「接続」画面で宛先、適用ルール、最終的なポリシーを確認します。PDF取得まで試す場合は、必要なときだけ行い、不要な大容量ダウンロードを繰り返さないでください。

ルールを追加しても通信が変わらない場合は、設定が有効か、対象ドメインが一致しているか、先に一致するルールがないかを順番に確認します。ブラウザー拡張や独自のプロキシ設定があると、OSのシステムプロキシとは別の経路になることがあります。調査中はTUN、システムプロキシ、ブラウザー個別設定を同時に何度も切り替えず、1つずつ確認すると原因を見つけやすくなります。

ZoteroとOverleafはサービス単位で確認する

Zoteroは文献情報や添付ファイルの同期に、複数の通信先を使用することがあります。Webライブラリが開くことと、デスクトップアプリの同期や添付ファイルの取得が成功することは同じではありません。まずZoteroの同期設定とエラー表示を確認し、Clashの接続履歴で、同期を実行した時刻にアクセスしたドメインを調べます。通信先を推測だけで広く許可せず、実際に必要なホストを確認してからルールを追加してください。

• Zoteroの書誌データ：同期時にどのホストへ接続したか、クライアントの表示とログを確認します。APIや同期サービスの接続先を変更する前に、Zoteroの公式設定とネットワーク案内を確認してください。
• 添付ファイル：書誌情報だけ同期できても、添付ファイルの保存先やダウンロード経路が別に失敗する場合があります。対象の項目を開き、同期状態とファイルの取得状況を分けて確認します。
• Overleaf：編集画面へのログイン、文書の保存、コンパイル、PDF取得をそれぞれ試します。ページの表示だけで判断せず、接続履歴で実際の通信がどのルールに一致したか確認します。
• 大学アカウント連携：学内のSSOからOverleafや文献データベースへ移動する場合、認証先を通常のサービスサイトと区別します。大学が指定する接続方式がある場合は、その指示を優先します。

「学術サービスはすべてプロキシ」と一括指定すると、大学の認証が想定外の経路へ流れたり、アクセス元の判定が変わったりする可能性があります。たとえば、文献検索はプロキシ経由、大学図書館とSSOは直接接続という構成が適切な場合もあれば、大学が提供するVPN接続を先に必要とする場合もあります。正解は所属機関のネットワーク設計と利用規則によって異なります。

プロキシを変更すると、接続元のIPアドレスやサービス側の地域判定が変わる場合があります。ログインの追加確認が表示されたときは、認証を繰り返す前に、大学の案内とサービスのアカウント保護手順を確認します。プロキシ接続を、学外から学内限定の契約コンテンツへアクセスするための認証回避手段として扱わないでください。

接続結果を比較し、失敗箇所を切り分ける

設定の評価は、ページが開いたかどうかだけでなく、どのルールが適用されたかを記録して行います。同じ端末、同じネットワーク、同じノードまたは直接接続の条件で比較し、一度に変更する項目を1つに絞ります。クライアントの「接続」画面にはドメイン、ルール、ポリシーが表示されることが多いため、該当リクエストの時刻と合わせて確認します。

Google Scholarから出版社へ移動した後のアクセス可否は、出版社の認証や所属機関の契約にも左右されます。Scholarのページがプロキシ経由で開いても、本文へのアクセス権が付与されるわけではありません。アクセス権があるはずなのに認証が通らない場合は、大学図書館の案内に従って学内VPNや機関ログインを確認し、Clashのルールを追加するだけで解決しようとしないでください。

最後に、設定を変える前の状態へ戻せるよう、編集したルールと変更日時を控えます。接続先のサービスや大学のネットワーク要件が変わったときは、以前のルールが適切とは限りません。定期的に実際の接続履歴を見直し、不要になった広域ルールを削除して、検索・文献管理・執筆・学内認証をそれぞれ必要な経路に保つことが、研究環境を安定して運用するポイントです。