研究者の通信を「すべてプロキシ」から分離する
Google Scholarで論文を検索し、Zoteroで文献情報とPDFを整理し、Overleafで共同執筆する場合、Clashをグローバルモードに固定するよりも、学術サービスだけを専用のプロキシグループへ振り分けるほうが管理しやすくなります。通常のWeb閲覧、大学の学内サービス、クラウドストレージ、OSの更新まで同じ経路に送ると、アクセス速度やログイン状態に影響が出ることがあります。まずは mode: rule を使い、対象ドメイン、接続先グループ、直接接続の順番を明示しましょう。
ここでいう振り分けは、所属機関や地域のアクセス制限を回避するためのものではありません。大学や研究機関のネットワークポリシー、出版社の利用規約、契約している電子ジャーナルのアクセス条件を確認し、利用が許可されたプロキシやVPNだけを設定してください。機関リポジトリや購読型データベースでは、認証済みの学内ネットワークや機関VPNが必要になる場合があります。
| 用途 | 代表的なドメイン | 推奨経路 | 確認するポイント |
|---|---|---|---|
| 論文検索 | scholar.google.com |
研究用プロキシ | 検索結果、CAPTCHA、引用リンクの表示 |
| 文献管理 | zotero.org |
研究用プロキシまたは直接 | アカウント認証、同期、添付ファイルの転送 |
| 共同執筆 | overleaf.com |
研究用プロキシ | ログイン、編集画面、コンパイル、共同編集 |
| 出版社・論文サイト | 出版社ごとに異なる | 機関の指定経路 | 認証方式、利用許可、PDFの取得条件 |
Google Scholar・Zotero・Overleafのルールを作る
下の例は、mihomo系カーネルで利用できる基本的なルール構成です。RESEARCH は実際に使うプロキシグループ名へ置き換えてください。グループ名に日本語を使う設定もありますが、手入力や移行時の誤りを減らすため、例ではASCII文字を使っています。設定のインデントはタブではなくスペースに統一します。
proxy-groups:
- name: RESEARCH
type: select
proxies:
- 自動選択
- DIRECT
rules:
- DOMAIN-SUFFIX,scholar.google.com,RESEARCH
- DOMAIN-SUFFIX,scholar.googleusercontent.com,RESEARCH
- DOMAIN-SUFFIX,zotero.org,RESEARCH
- DOMAIN-SUFFIX,overleaf.com,RESEARCH
- MATCH,DIRECTDOMAIN-SUFFIX は指定したドメイン自身と、そのサブドメインに一致します。Google Scholarの検索画面だけでなく、検索結果から表示される関連リソースや引用情報を確認するため、必要に応じて scholar.googleusercontent.com も追加します。ただし、Google検索、Gmail、Google Driveまで自動的に研究用プロキシへ送られるわけではありません。対象範囲を広げたい場合は、実際の接続ログを見てから個別に追加してください。
Zoteroはデスクトップアプリ、ブラウザーのZotero Connector、Zoteroの同期サーバー、添付ファイルの保存先という複数の通信を使います。基本的なアカウント同期は zotero.org とそのサブドメインで動作しますが、機関のWebDAVや独自ストレージを使っている場合は別のホスト名が必要です。Overleafではログインとプロジェクト編集だけでなく、コンパイル結果、画像、参考文献ファイル、共同編集用の通信も関係します。ブラウザーに表示されるURLだけで判断せず、Clashの接続一覧で実際のホスト名を確認してください。
ルールの順番とプロキシグループを確認する
Clashのルールは通常、上から順番に評価され、最初に一致したルールが採用されます。研究用ドメインのルールを MATCH,DIRECT より下に置くと、先に全通信を直接接続へ送ってしまいます。逆に、広すぎる DOMAIN-SUFFIX,google.com,RESEARCH を上部へ置くと、研究検索とは無関係なGoogleサービスまで同じ経路になります。具体的なドメインを先に、一般的なルールを後に配置するのが基本です。
プロキシグループに DIRECT を含めるかどうかは、利用環境に合わせて決めます。認証済みの機関ネットワークでのみアクセスできるサービスを扱う場合、勝手に別経路へ切り替わると認証条件や利用記録に影響する可能性があります。一方、研究用サービスが一時的に利用できないときに直接接続を試したい場合は、手動選択にして利用者が経路を明示できるようにします。自動選択だけに任せると、遅延が低いノードへ切り替わってもログインセッションが再認証になることがあります。
実際に設定して動作を検証する手順
設定を変更する前に、現在のプロファイルを複製するか、元のYAMLをバックアップします。購読設定を直接編集すると、次回更新時に変更内容が上書きされることがあります。クライアントに「オーバーライド」「Mixin」「拡張設定」がある場合は、購読設定本体ではなく、その機能でルールを追加できるか確認してください。機能名や保存場所はFlClash、Clash Verge Rev、Clash for Windows系クライアントで異なります。
- Clashクライアントで現在使用中のプロファイルを確認し、設定ファイルまたはオーバーライドをバックアップします。
- 研究用のプロキシグループを作成し、利用するノード、遅延テストのURL、必要なら
DIRECTを登録します。 scholar.google.com、zotero.org、overleaf.comのルールをMATCHより上に追加します。- 設定を保存して読み込み直し、必要であればmihomoカーネルを再起動します。
- ブラウザーでGoogle Scholarを開き、検索、論文詳細、引用情報の表示を順番に確認します。
- Zoteroでアカウント情報を確認し、短いテストコレクションを作成して同期を実行します。
- Overleafで既存プロジェクトを開き、編集、保存、コンパイル、PDFプレビューまで試します。
- Clashの接続ログで、対象ドメインが意図した
RESEARCHグループへ送られたことを確認します。
ブラウザーのキャッシュや既存のログインCookieが残っていると、経路を変更しても表示が続くことがあります。検証ではプライベートウィンドウを使うか、対象サイトから一度ログアウトして、DNSキャッシュと接続履歴を確認します。ただし、大学SSOや多要素認証を利用している場合は、無闇にCookieを削除すると再認証が必要になります。認証アプリやバックアップコードを準備してから操作してください。
# 設定反映後に確認する項目
mode: rule
mixed-port: 7890
allow-lan: false
# 研究用ドメインは具体的なルールを先に置く
rules:
- DOMAIN-SUFFIX,scholar.google.com,RESEARCH
- DOMAIN-SUFFIX,zotero.org,RESEARCH
- DOMAIN-SUFFIX,overleaf.com,RESEARCH
- MATCH,DIRECT接続ログには、ドメイン、使用した策略グループ、接続結果、場合によっては接続先IPが表示されます。Google Scholarが開けても、Zoteroの同期やOverleafのコンパイルが失敗する場合は、サイト全体の疎通ではなく、別ホスト、証明書検証、WebSocket、ファイル転送のどこかで問題が起きている可能性があります。ログを一つずつ確認し、複数の設定を同時に変えないことが重要です。
Zotero同期とOverleaf連携で確認すべき点
Zoteroの同期には、文献データの同期と添付ファイルの同期という別の要素があります。タイトル、著者、タグ、コレクションが同期できても、PDFやスナップショットが同期できるとは限りません。Zoteroの同期設定で「データの同期」と「ファイルの同期」を分けて確認し、保存容量、ファイル同期方式、WebDAVのホスト名を記録してください。プロキシの切り替え後に文献情報だけが更新される場合は、添付ファイルの保存先への接続が別経路になっている可能性があります。
| 症状 | 考えられる原因 | 確認方法 |
|---|---|---|
| ログイン画面が繰り返し表示される | 認証Cookie、時刻、SSO経路の不一致 | 同じプロキシグループでログインから再実行 |
| 文献情報は同期するがPDFがない | ファイル同期またはWebDAVの接続失敗 | Zoteroの同期ログと接続先ホストを確認 |
| Overleafは開くがコンパイルが止まる | コンパイルサービス、画像、参考文献ファイルの通信失敗 | プロジェクトログとClashの接続一覧を照合 |
| Scholarで頻繁に確認画面が出る | 短時間の大量検索、共有IPの評価、経路変更 | 検索頻度を下げ、ノードを固定して再確認 |
OverleafでZoteroの文献を使う場合、一般的にはZoteroからBibTeXまたはBibLaTeX形式で書き出し、Overleafプロジェクトへ取り込みます。連携方式によっては、ブラウザーの拡張機能、クラウド同期、プロジェクト側の参考文献ファイルが別々に動作します。Clashのルールを追加しても、BibTeXのキー重複、文字コード、引用スタイル、.bib ファイルのアップロード漏れは解決しません。通信問題とLaTeXのコンパイル問題を分けて調査してください。
共同執筆では、Overleafの編集画面だけでなく、共有プロジェクトへの招待、コメント、変更履歴、PDFプレビューも確認します。特定のノードだけでWebSocketが不安定になる場合は、同じ研究用グループ内で別ノードを手動選択し、接続が安定するか比較します。短時間で何度もノードを切り替えると、ログインセッションや共同編集接続が再確立されるため、測定時は1つのノードを数分固定してください。
研究用ルールを長期運用する
研究サービスのドメインやログイン方式は変わることがあります。設定を作った後も、月に一度程度、Google Scholarの検索、Zoteroのデータ同期と添付ファイル同期、Overleafのコンパイルを短いテストで確認すると、締切直前のトラブルを減らせます。ノード更新や購読更新の直後は、プロキシグループ名が変更されていないか、古いグループを参照していないか確認してください。
ルールを増やすときは、対象、目的、経路をコメントや別のメモに記録します。たとえば出版社用ルールを追加する場合は、ドメイン名だけでなく、機関VPNが必要か、直接接続が許可されているか、PDF取得まで同じ経路かを書き残します。TUNモードを使う場合は、ブラウザーだけでなくZotero、LaTeX関連ツール、ターミナルの通信も取り込まれます。まずシステムプロキシで動作を確認し、必要なアプリがプロキシを参照しない場合だけTUNを検討するのが安全です。
# 追加時に残しておく管理メモの例
研究用ルール:
scholar.google.com: 検索結果の確認
zotero.org: アカウントとデータ同期
overleaf.com: 編集とコンパイル
確認日: 2026-09-04
検証内容: 検索、同期、PDFプレビュー
注意: 出版社ドメインは機関ポリシーを確認してから追加学術サイトだけを振り分ける構成では、通信範囲を限定できる一方、サービスごとに異なる認証、CDN、ファイル保存先を確認する必要があります。研究用プロキシを常時自動選択にせず、手動切り替えできるプロキシグループとして用意し、接続ログと各サービスの同期状態を照合してください。この運用なら、論文検索、文献管理、共同執筆を分離しながら、普段の通信への影響も抑えられます。