はじめに
研究者にとって、ネットワーク環境は論文執筆や情報収集の効率を左右する重要な作業基盤です。Google Scholar で文献を検索し、出版社のページから本文を確認し、Zotero で書誌情報とPDFを整理するという流れは、日常的な研究活動の一部になっています。さらに、Overleaf、GitHub、ORCID、Crossref などを組み合わせる場合、接続先が増えるほど「どの通信をどの経路に通すか」が複雑になります。
すべての通信を同じプロキシに通すだけでは、国内サービスまで遅くなったり、Zoteroの同期が不安定になったりすることがあります。一方で、学術検索や海外出版社だけを無条件に DIRECT にすると、接続できない、認証画面が繰り返し表示される、PDFのダウンロードだけ失敗するといった問題が起こりやすくなります。
本記事では、Clash Verge Rev や Mihomo を中心に、研究用途に適した分流ルール、DNS、TUNモード、Zotero同期の確認方法を順番に解説します。特定のサービスの利用制限を不正に回避することではなく、正規のアカウントと契約、所属機関のアクセス権を前提に、通信経路を安定させることが目的です。
この記事の目標
Google Scholar、Zotero、出版社サイト、Overleafを用途別に振り分け、検索・保存・執筆・同期を安定して行えるClash環境を作ります。
1研究用途で分流が必要な理由
研究活動で使うサービスは、同じ「ウェブサイト」に見えても、通信の性質がそれぞれ異なります。Google Scholarは検索結果や引用情報を取得する通信が中心ですが、検索結果から移動した出版社サイトでは、HTML、JavaScript、認証、PDF配信サーバーが別々のドメインを使うことがあります。ZoteroはWeb Libraryだけでなく、同期用のAPIやストレージにも接続するため、トップページが開いていても同期だけ失敗する場合があります。
| 用途 | 代表的な接続先 | 基本方針 | 確認したい症状 |
|---|---|---|---|
| 文献検索 | Google Scholar、Semantic Scholar | 検索専用グループへ振り分け | 検索結果、引用リンク、CAPTCHA |
| 論文本文 | 出版社、機関リポジトリ | サイトごとに経路を調整 | HTML表示、PDF、認証 |
| 書誌管理 | Zotero、Web Library | 同期と保存を分けて確認 | 同期状態、添付ファイル、API |
| 執筆・共有 | Overleaf、GitHub、ORCID | 安定性とログイン維持を優先 | コンパイル、Git操作、OAuth |
このように用途ごとにプロキシグループを分けると、研究中に一つのノードが混雑しても、他の作業まで巻き込まれにくくなります。特に、検索用、執筆用、通常通信の3グループを最初に用意し、必要な場合だけ出版社やストレージ用のグループを追加する構成が扱いやすいでしょう。
2Clashクライアントと基本設定
Windows、macOS、Linuxのデスクトップであれば、Mihomoコアに対応した Clash Verge Rev が研究用途に向いています。設定画面からプロファイルを読み込み、カーネルが正常に起動していることを確認してください。Clash for Windowsなど別のクライアントを使う場合も、名称は異なりますが、プロファイル、プロキシモード、DNS、システムプロキシという考え方は共通しています。
- 信頼できるプロバイダーのサブスクリプションをプロファイルへ追加し、更新日時を確認します。
- プロキシグループに、用途が分かる名前を付けます。例として
Scholar、Research、Writing、DIRECTを用意します。 - 最初はルールモードを選択し、グローバルモードで全通信をプロキシに通す設定は避けます。
- WindowsやmacOSのシステムプロキシを有効にし、ブラウザーで通常のページが開くことを確認します。
- ブラウザーだけでなくZoteroやOverleafのデスクトップアプリも使う場合は、後述のTUNモードを検討します。
ノードは速度だけでなく、接続の安定性、切断後の復帰、認証ページとの相性を見て選びます。研究中に長時間PDFをダウンロードするなら、瞬間的な速度よりもパケットロスの少なさが重要です。複数のノードを同じグループに登録し、手動選択とURLテストを使い分けると、障害時の切り替えも簡単になります。
利用上の注意
大学や研究機関の規程、出版社の利用条件、APIのレート制限を守ってください。大量の自動検索や短時間の連続アクセスは、プロキシ設定に関係なくアカウントやIPの制限を招く可能性があります。
3DNSとTUNモードを整える
学術サイトの接続問題では、プロキシノードそのものよりもDNSの経路が原因になることがあります。ブラウザーがドメイン名を解決する際に、ローカルDNSとプロキシ側の通信が混在すると、ページは表示されるのにPDFだけ接続できない、あるいはログイン後に別ドメインへ移動した瞬間に失敗することがあります。
fake-ip は多くのアプリで名前解決を効率化できますが、研究機関の認証システムや一部のネットワーク機器と相性が合わない場合があります。ログイン画面がループする、Zoteroの同期がタイムアウトするなどの症状が出たら、対象ドメインを fake-ip-filter に追加するか、テスト用に redir-host へ変更して比較してください。
TUNモードは、システムプロキシに対応していないアプリケーションの通信もClashへ取り込む仕組みです。Zoteroの同期、PDFリーダーのリンク、Git、Overleaf関連の補助ツールまで一貫して確認したい場合に有効です。ただし、管理者権限やネットワーク拡張機能が必要になることがあり、仮想マシン、Docker、VPN、大学のセキュリティソフトと競合することもあります。
- ブラウザーだけを使う： まずシステムプロキシで十分か確認します。
- Zoteroアプリも同期する： TUNモードを有効にし、DNSとルールのログを確認します。
- 社内・学内ネットワーク： TUNを常時オンにせず、規程や既存VPNとの併用可否を確認します。
4Google Scholarと学術サイトの分流ルール
ルールは上から順番に評価されるため、特定ドメインのルールを一般的なルールより前に置くことが重要です。プロキシグループ名は、実際の設定に存在する名前へ置き換えてください。次の例では、Google Scholarと研究関連サービスを専用グループへ送り、国内サービスやローカルネットワークは直接接続にしています。
Google Scholarの検索ページだけでなく、検索結果から開く引用情報やキャッシュ、出版社への遷移も確認してください。特定の出版社をよく使う場合は、そのドメインを一括で追加するのではなく、実際のブラウザー開発者ツールやClashの接続ログで確認したドメインだけを登録します。広告、アクセス解析、画像配信のドメインまで無制限に同じグループへ入れると、接続数が増えてかえって不安定になることがあります。
設定のポイント
ルールを書いた後は、ClashのConnections画面で実際のドメインと使用グループを確認してください。ルール名が一致していても、リダイレクト先やPDF配信先が別ドメインなら追加調整が必要です。
ルールの優先順位を確認する
DOMAIN-SUFFIX は対象ドメインとそのサブドメインをまとめて指定できますが、ドメインの入力ミスには注意が必要です。たとえば google.com を広く指定すると、研究目的ではないGoogleサービスまで同じ経路になる可能性があります。検索用のルールを細かくし、最後の MATCH は予備の経路として残す構成が安全です。
5Zoteroの同期と保存を安定させる
Zoteroでは、書誌情報の同期と添付ファイルの同期を別々に考える必要があります。タイトル、著者、コレクションなどのデータは同期できても、PDFやスナップショットだけ失敗する場合があります。逆に、添付ファイルは保存されていても、Web Library側の情報が更新されていないケースもあります。
| 確認項目 | 見直す内容 | 切り分け方法 |
|---|---|---|
| アカウント | Zotero IDとパスワード、二段階認証 | ブラウザーでWeb Libraryへログイン |
| データ同期 | 書誌情報とコレクション | 小さなテスト項目を作成して同期 |
| ファイル同期 | PDF、スナップショット、ストレージ容量 | 小容量のPDFでアップロードを確認 |
| プロキシ経路 | API、ログイン、ストレージ | Connectionsとログを同時に確認 |
まずZoteroを終了し、ClashのシステムプロキシまたはTUNモードを有効にしてから、Zoteroを再起動します。同期ボタンを押した直後にConnectionsへ表示されるドメインを記録し、タイムアウトやTLSエラーがないかを確認してください。プロキシを経由すると同期できない場合は、同じドメインを一時的に DIRECT にして比較します。これで改善するならノードや経路の問題、どちらでも失敗するならアカウント、容量、Zotero側の設定を疑います。
論文PDFの取得では、出版社の利用許諾や大学図書館の認証を優先してください。ブラウザーで機関認証を完了した後、Zotero Connectorで保存する流れが安定しやすい一方、認証情報を第三者へ渡したり、規約に反する大量取得を行ったりすることは避けるべきです。PDFが保存できない場合は、ファイル名の長さ、保存先の権限、ストレージ容量も確認します。
6接続トラブルの診断手順
研究中に突然アクセスできなくなった場合、設定を一度に複数変更すると原因が分からなくなります。次の順番で、一項目ずつ確認してください。
- Clashの状態： コアが起動しているか、プロファイルが期限切れになっていないか確認します。
- ノードの状態： 同じグループ内の別ノードへ切り替え、遅延とパケットロスを比較します。
- ルールの状態： Connectionsで対象ドメインが想定したグループへ入っているか確認します。
- DNSの状態： DNSエラー、名前解決の遅延、fake-ipとの相性を確認します。
- アプリの状態： ブラウザーだけでなくZoteroやGitなど、問題が出ているアプリを再起動します。
- 認証の状態： CookieやOAuthセッションを削除する前に、所属機関のログイン方法を確認します。
- 検索ページだけ遅い： Scholarグループのノードを変更し、DNS応答とCAPTCHAの表示を確認します。
- PDFだけ失敗する： PDF配信ドメインが別ルールへ入っていないか、機関認証が切れていないか確認します。
- Zoteroが同期しない： TUNモード、TLSエラー、アカウント容量、システム時刻を確認します。
- Overleafが切断される： Writingグループを固定し、頻繁なノード自動切り替えを一時停止します。
- すべてのサイトが遅い： プロキシを一度停止して回線を比較し、問題がClashか回線側かを切り分けます。
最後に、安定した状態のプロファイルをバックアップしておきましょう。ルールを追加する際は、日付や目的をコメントで残し、変更前後にGoogle Scholarの検索、出版社の本文表示、Zoteroの小容量同期、Overleafのコンパイルという4つのテストを実行します。研究の締切直前に大幅な設定変更をしないことも、実用上かなり重要です。
Clashは、研究者の通信を自動的に高速化する魔法のツールではありません。しかし、サービスごとの経路を観察し、DNS・ルール・ノード・アプリ設定を分けて管理すれば、論文検索から引用管理、執筆、同期までをより再現性のある環境で運用できます。最初は少数のルールから始め、ログを見ながら必要なドメインだけを追加してください。