設定 Clash初心者 VPNとの違い プロキシ入門

研究者向けClash設定術:Scholar・Zotero・Overleafを快適化

2026年8月17日 更新日:2026年8月17日 読了目安:約10分

研究者のためのClash活用法

文献検索、参考文献の整理、共同執筆を毎日行う研究者にとって、ネットワークの不安定さは単なる不便ではありません。Google Scholar で検索結果が表示されない、論文 PDF のダウンロードが途中で止まる、Zotero の同期が何度も失敗する、Overleaf の編集画面が読み込まれないといった問題は、研究の流れを大きく中断させます。特に、複数の学術サービスを同時に使う環境では、サービスごとに必要な接続先や通信特性が異なるため、すべての通信を一律にプロキシへ送る方法が最適とは限りません。

Clash は、ドメインや通信の種類に応じて、プロキシ経由、直接接続、特定のノードグループなどを細かく振り分けられるルールベースのネットワークツールです。本記事では、Clash Verge Rev や Mihomo を想定し、Google Scholar、Zotero、Overleaf を研究用途に合わせて安定させる考え方を解説します。重要なのは、サービス名だけで判断するのではなく、ログを確認しながら必要なドメインを段階的に追加することです。

この記事の目標

文献検索、文献管理、論文執筆の通信を用途別に整理し、研究作業を中断させる接続エラーや同期遅延を減らします。

学術サービスで起きやすい接続問題

研究用サービスの接続が不安定になる原因は、一つとは限りません。Google Scholar は検索ページだけでなく、検索結果から出版社、大学リポジトリ、DOI サービス、PDF 配信先へ移動します。そのため Scholar 本体が開けても、論文本文の取得段階で別の遅延やタイムアウトが発生することがあります。検索を短時間に繰り返すと、アクセス頻度による確認画面が表示される場合もあります。

Zotero では、ウェブブラウザーからのメタデータ取得、添付ファイルのダウンロード、Zotero Storage との同期が別々の通信として動作します。WebDAV や機関内サーバーを利用している場合は、クラウド同期だけをプロキシに通すと、かえってローカルの同期が遅くなることがあります。Overleaf も、編集ページ、プロジェクト API、画像やフォントなどの静的ファイル、共同編集用のリアルタイム接続を複数のホストで処理します。

  • 検索と本文取得の経路が異なる: Scholar の検索結果から移動した先の出版社やリポジトリが、別の接続条件を要求することがあります。
  • 同期は長時間通信になりやすい: Zotero の大量ファイル同期では、短時間の切断でも再試行が発生し、完了までの時間が延びます。
  • Overleaf は常時接続を使う: 編集画面の表示だけでなく、共同編集やコンパイル結果の更新にも安定した接続が必要です。
  • DNS の経路が一貫しない: DNS だけ直接接続、ウェブ通信はプロキシという組み合わせでは、名前解決と実際の接続先に差が生じる場合があります。

先に確認したいこと

Clash は接続先そのものを提供するソフトウェアではありません。信頼できるサブスクリプション、利用規約に適合したノード、大学や研究機関のネットワークポリシーを確認したうえで使用してください。

1サービス別の分流設計

まず、研究で使うサービスを同じグループに入れず、役割ごとに整理します。一般的には、学術検索と本文取得、文献管理のクラウド同期、論文執筆環境を別のルールとして管理すると、問題が発生したときに原因を切り分けやすくなります。ノードグループ名は、例えば AcademicReferenceSyncWriting のように用途で付けると、後から設定を見直す際にも分かりやすくなります。

研究サービスの推奨ルール方針
用途 主な対象 初期方針 確認ポイント
文献検索 Google Scholar、検索関連ドメイン Academic 経由 検索結果と確認画面の表示
本文取得 出版社、大学リポジトリ、DOI 関連先 必要に応じて Academic PDF の開始速度と再接続
文献同期 Zotero の同期先、WebDAV ReferenceSync 経由 メタデータと添付ファイルの同期
論文執筆 Overleaf と関連静的リソース Writing 経由 編集、保存、コンパイル結果
国内サービス 大学ポータル、学内 VPN、国内サイト DIRECT 認証と学内アクセスの維持

ルールを作るときは、まず公式ドメインや実際のアクセスログで確認できたドメインだけを登録します。推測で広い DOMAIN-KEYWORD を追加すると、関係のないサイトまで同じノードへ送られたり、学内システムが利用できなくなったりします。特に大学の認証ページや図書館の電子ジャーナル入口は、学内ネットワークからの直接接続を要求することがあるため、プロキシ経由にする前に管理者の案内を確認してください。

2Clash Verge Rev で実際に設定する手順

ここでは、既存のプロファイルを壊さずに研究用ルールを追加する流れを紹介します。画面の名称はクライアントやバージョンによって異なりますが、Clash Verge Rev ではプロファイルの編集、Merge、またはルール設定の機能を利用できます。元の設定を直接上書きする前に、必ずプロファイルを複製するか、設定ファイルをバックアップしてください。

基本設定の手順
  1. Clash Verge Rev を起動し、使用中のプロファイルと Mihomo コアが正常に読み込まれていることを確認します。
  2. 研究用に使うノードグループを一つ選び、低遅延だけでなく、接続の安定性、通信量、長時間接続の実績も確認します。
  3. 必要に応じて TUN モードを有効にします。ブラウザーだけでなく Zotero や Overleaf のデスクトップ通信も制御したい場合に有効です。
  4. DNS 設定を確認し、プロキシ通信と名前解決の経路が極端に分離しないようにします。設定変更後は Clash を再起動して反映を確認します。
  5. Google Scholar、Zotero、Overleaf を一つずつ開き、Clash の接続ログで実際に利用されたドメインとルール名を確認します。
rules: - DOMAIN-SUFFIX,scholar.google.com,Academic - DOMAIN-SUFFIX,zotero.org,ReferenceSync - DOMAIN-SUFFIX,overleaf.com,Writing - DOMAIN-SUFFIX,大学のドメイン,DIRECT - MATCH,DIRECT

上記は考え方を示す最小例です。大学のドメイン は実際の所属機関のドメインに置き換え、プロバイダーが提供する既存ルールの後ろに無条件で貼り付けないでください。Clash のルールは上から順に評価されるため、広いルールが先にあると、後から追加した学術サービスのルールに到達しないことがあります。

ログを使って不足ドメインを見つける

Overleaf の編集ページが開いてもコンパイル結果だけ表示されない場合や、Zotero のメタデータは同期できても添付 PDF が同期されない場合は、サービス本体以外のドメインが未設定である可能性があります。対象アプリを終了せず、Clash のログ画面で接続先を確認し、同じ用途のドメインだけを追加します。追加するたびに一つの操作を再実行し、改善したかを記録すると、不要なルールの増加を防げます。

3DNS、TUN、ノードを安定させる

研究用途では、瞬間的な速度よりも長時間の安定性が重要です。論文 PDF の取得や Zotero の添付ファイル同期では、速度測定の数値が高くてもパケットロスが多いノードは実用的ではありません。複数のノードを同じグループに登録し、一定時間ごとの遅延だけでなく、実際の検索、ダウンロード、アップロードで比較してください。

DNS は、学術サイトのドメインを正しく解決するための入口です。Mihomo の DNS を利用する場合は、利用環境に合った nameserverfallback を設定し、必要であれば特定ドメインの名前解決ポリシーを分けます。ただし、複雑な DNS 設定を一度に導入すると、問題の原因が分かりにくくなります。最初は動作する基本設定から始め、タイムアウトや誤った地域判定が見られるときだけ調整しましょう。

TUN モードの注意点

TUN モードはシステム全体の通信を捕捉できる一方、大学 VPN、セキュリティソフト、Docker、仮想マシンと競合することがあります。学内サービスに接続できなくなった場合は、TUN を一度無効にし、システムプロキシだけで再現するか確認してください。

  • 同一ノードを固定しすぎない: 混雑や障害に備え、研究用グループに複数の候補を用意します。
  • 自動選択だけに任せない: 遅延が低くても、論文サイトとの相性や長時間接続の安定性が異なる場合があります。
  • IPv6 の挙動を確認する: IPv4 と IPv6 で異なる経路を使う環境では、接続先の判定が不安定になることがあります。
  • 大容量同期を分ける: Zotero の大量添付ファイル同期は、Overleaf のコンパイルやオンライン会議と同時に実行しない方が安全です。

4よくある症状と切り分け方

設定後に問題が残る場合は、Clash の設定だけを繰り返し変更するのではなく、サービス、アプリケーション、ネットワークの三つに分けて確認します。まずブラウザーのプライベートウィンドウで対象サイトを開き、次に別のノード、最後に DIRECT へ切り替えて挙動を比較します。これにより、認証情報の問題なのか、ノードの品質なのか、ルールの誤りなのかを判断しやすくなります。

症状別チェックリスト
  • Scholar の検索だけ失敗する: ブラウザーの Cookie や確認画面を確認し、短時間の連続検索を避けます。別ノードで同じ症状が出るかも確認します。
  • PDF が途中で止まる: 出版社やリポジトリのドメインが別ルールになっていないか、ノードのパケットロスが多くないかを調べます。
  • Zotero が同期を繰り返す: 同期先の容量、アカウント状態、WebDAV の認証を確認したうえで、添付ファイルだけを小分けに同期します。
  • Overleaf が保存できない: ブラウザー拡張を一時停止し、WebSocket に関係する接続がログで拒否されていないかを確認します。
  • 学内サイトが開かない: 学内 VPN や認証サービスを DIRECT に戻し、大学が指定する DNS と VPN の順序に従います。

設定が安定したら、変更内容を YAML ファイルやメモに残し、どのルールがどの症状を改善したかを記録しておきましょう。研究室の複数端末で同じ設定を使う場合も、個人アカウント、大学 VPN、保存先の違いをそのまま共有しないことが大切です。サブスクリプションの更新後はルールの優先順位やプロキシグループ名が変わることがあるため、アップデート後に主要サービスを一度ずつテストしてください。

Clash の分流設定は、一度完成させたら終わりというものではありません。研究環境では、投稿先の出版社、所属機関の認証方式、Zotero の保存先、Overleaf の機能が変わることがあります。必要最小限のドメインだけを対象にし、DIRECT とプロキシの境界を定期的に見直すことが、速度、安定性、管理しやすさを両立する最も現実的な方法です。

Clashを無料でダウンロード — 快適な研究環境をはじめよう →