研究者向けClash設定術：ZoteroとOverleafを安定化する実践ガイド

この記事で分かること

研究者のネットワーク環境では、一般的なウェブ閲覧だけでなく、学術検索、文献データベース、Zoteroの同期、Overleafでの共同執筆を同時に安定させる必要があります。ブラウザで論文ページが開いていても、Zoteroの添付ファイル取得だけが止まったり、Overleafの編集画面は表示されるのにコンパイル結果の更新が遅れたりすることがあります。このような現象は、回線全体の障害ではなく、アプリごとに参照するプロキシ設定、DNS、認証経路が異なることから発生します。

本稿では、ClashまたはMihomo系クライアントを研究用パソコンで運用する前提で、用途ごとのルール分流、DNSの考え方、システムプロキシと環境変数の使い分け、ZoteroとOverleafの接続確認、トラブル発生時のログの読み方を順に整理します。特定のサービスを無条件にすべてプロキシへ送るのではなく、大学ポータルや研究室内のサービスはDIRECT、外部の学術サービスは必要に応じてPROXYという境界を作ることが目標です。

なお、大学や研究機関によっては、外部プロキシ、VPN、論文データベースへのアクセス方法に独自の規約があります。設定を変更する前に、所属機関の情報セキュリティ規程、図書館のリモートアクセス案内、研究データの取り扱い基準を確認してください。Clashは接続経路を整理する道具であり、契約や認証の制限を回避するためのものではありません。

研究ワークフローを三つの通信に分ける

最初に、研究作業を一つの「海外サイト」として扱わないことが重要です。実際には、論文を探す通信、文献情報を同期する通信、原稿を編集してビルドする通信には、それぞれ異なるホストと接続時間があります。これらを同じノードへ無理に集約すると、検索は速くても添付ファイルが遅い、またはOverleafの長いセッションだけが切れるという状態になりやすいです。

• 学術検索：Google Scholar、出版社、プレプリント、大学図書館の検索システムなど。短いHTTPS接続が多く、検索結果やPDFの配信元が複数に分かれます。
• 文献管理：Zoteroのアカウント認証、ライブラリ同期、WebDAVなどの添付ファイル保存先。メタデータとPDFファイルでは通信先や転送時間が異なります。
• 共同執筆：Overleafのログイン、プロジェクト編集、Git連携、コンパイル結果、画像や参考文献の取得。画面表示後もバックグラウンド通信が続く点が特徴です。

この分類を先に作ると、Clashのログで問題のホストを見つけたとき、「すべてをPROXYにする」という大雑把な対応を避けられます。たとえば、学内の認証ページはDIRECTのまま、論文出版社のドメインだけをPROXYへ送る構成が考えられます。また、Zoteroの同期は同じアカウントを使っていても、添付ファイルの保存先が別サービスなら、同期画面に表示されるホストを個別に確認する必要があります。

設定前に確認する項目

設定作業の前に、現在の状態を簡単に記録してください。Clashのクライアント名とバージョン、使用中のコア、プロファイル名、mixed-port、DNSモード、システムプロキシの有効状態をメモします。加えて、大学VPNやゼロトラスト製品、ブラウザ拡張のプロキシ機能が動いていないか確認します。複数の経路が同時に有効だと、Clashのルールを変更しても実際のパケットが別の仮想NICを通り、検証結果が安定しません。

WindowsではシステムプロキシとWinHTTPの設定が別になっている場合があります。macOSではシステム設定のネットワークサービスごとにプロキシが分かれ、Linuxではデスクトップ環境とシェルの環境変数が一致しないことがあります。研究室の共有端末や管理対象端末では、管理者が指定した設定を勝手に上書きせず、許可された範囲で調整してください。

Clashのルール分流を設計する

Clashのルールは、通信先のドメインやIP、プロセスなどを条件にして、PROXY、DIRECT、特定のポリシーグループへ振り分ける仕組みです。研究用途では、最初から広いキーワードルールを入れるより、接続ログで確認したホストを小さく追加する方法が安全です。たとえば、ドメイン名に「research」や「paper」が含まれるという理由だけで一括転送すると、関係のない国内サービスまでプロキシ経由になり、認証や速度に問題が出る可能性があります。

まず、研究室のイントラネット、大学ポータル、学内VPN、学内図書館サービスなど、所属機関の公式サービスをDIRECT側に整理します。ただし、大学のリモートアクセスが指定VPNを必要とする場合は、単純なDIRECTではなく、大学が案内する正式な経路を優先します。そのうえで、外部学術サイト、出版社、プレプリントサービス、Overleafなどの接続ログを確認し、必要なものだけを研究用のポリシーグループに割り当てます。

学術サイトと出版社の扱い

学術検索では、検索サイト本体と検索結果から遷移する出版社のサイトが別ドメインになることが珍しくありません。検索ページが開いたからといって、PDF配信サーバーや引用情報のAPIまで同じ経路を通るとは限りません。論文を開く、PDFを保存する、参考文献情報を取得するという三つの操作を順番に行い、それぞれのタイミングでClashの接続ログを確認します。

ルールを追加するときは、まず完全なドメインを対象にするDOMAINを使い、関連サブドメインが複数あると確認できた場合だけDOMAIN-SUFFIXへ広げます。広いsuffixを使う場合も、大学内の同名ドメインや認証用ホストを巻き込まないかを検討してください。ルールの順番は非常に重要で、上にあるルールが先に適用されるため、最後のMATCHより前に研究用ルールを配置します。

Zoteroの同期経路を確認する

Zoteroのトラブルは、「アプリは起動するが同期が終わらない」「コレクションは同期するがPDFが表示されない」「ログイン画面だけ繰り返し出る」という形で現れます。これらは必ずしも同じ原因ではありません。アカウント認証、ライブラリのメタデータ、添付ファイルの保存先、WebDAVなどを別々の通信として考える必要があります。

同期を開始する前に、Clashのログを開いておき、Zoteroの同期ボタンを一度だけ押します。短時間に大量のログが出る場合は、ドメイン名をコピーして一覧化し、認証、API、添付ファイルの三分類に分けます。公式ドメインを推測で追加するのではなく、実際のログに出た接続先を根拠にするのがポイントです。添付ファイルだけが失敗する場合は、保存先のWebDAV事業者やクラウドストレージのホストを見落としていないか確認します。

Overleafの長時間接続に注意する

Overleafは、ページを開いてHTMLを取得するだけのサービスではありません。プロジェクト編集時には、編集内容の送受信、コンパイル状態、ログ、PDFプレビュー、画像や参考文献ファイルの転送が続きます。そのため、最初の画面表示が成功しても、しばらく操作した後に「接続が切れました」と表示されることがあります。

この場合は、Overleafの主要ドメインだけでなく、ログに現れる静的ファイル配信先やリアルタイム通信先も確認します。WebSocketに近い長時間接続が別経路へ落ちると、短いリクエストは成功しているのに編集状態だけ更新されないことがあります。Clashのログで接続が頻繁に再確立されていないか、ノードの切り替えが起きていないか、ルールが途中でDIRECTへ変わっていないかを調べてください。

システムプロキシと環境変数を使い分ける

ブラウザはClashのシステムプロキシ設定を利用できても、Zoteroやコマンドラインツールが同じ設定を読むとは限りません。研究用の環境では、GUIアプリ、ブラウザ、Git、LaTeX関連ツール、OverleafのCLIがそれぞれ異なる実装を持つため、どの層でプロキシを指定するかを分けて考えます。

まずはClashの「システムプロキシ設定」を有効にし、ブラウザで学術サイトへ接続できるかを確認します。次にZoteroの同期を実行し、アプリ側にプロキシ設定がある場合は、大学や組織の推奨値とClashのmixed-portを照合します。設定画面にプロキシ項目がない、または挙動が不明な場合は、アプリのログとClashのログを同じ時刻に比較します。

ターミナルでGit連携やLaTeX関連の取得を行う場合は、HTTPS_PROXY、HTTP_PROXY、必要に応じてALL_PROXYを設定します。ローカルホストや大学内のプライベートアドレスはNO_PROXYへ入れ、ローカルのコンパイルサービスや研究室内サーバーへの通信がプロキシへ戻らないようにします。

# Example for a temporary research session
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export ALL_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1,.local

環境変数はシェルを起動した時点で読み込まれるため、設定後に開きっぱなしのターミナルやIDEをそのまま使うと反映されないことがあります。新しいターミナルを開き、env | grep -i proxyで値を確認してください。また、sudoやsystemdサービスは通常のユーザー環境を引き継がないため、研究用スクリプトをサービス化する場合は、サービス定義側で安全に設定する必要があります。

DNSと認証を安定させる

学術サイトやOverleafに接続できない原因を、すぐにノード品質だけで判断してはいけません。ドメイン名が正しく解決されていない、DNS応答が別の経路へ出ている、fake-ipとアプリの挙動が合っていない、といった名前解決の問題もあります。特に、ブラウザでは開くのにZoteroだけ失敗する場合は、アプリが独自のDNSキャッシュを持っている可能性があります。

ClashのDNSモードを変更する場合は、複数の項目を同時に変えないでください。最初に現在の設定をバックアップし、DNSモードだけを変更して、同じURLへ再接続します。改善した場合は、Clashログ、OSのDNSキャッシュ、アプリの再起動のどれが影響したのかを記録します。研究室の内部ドメインを外部DNSへ送ることが情報管理上問題になる場合もあるため、Split DNSの扱いは管理者の方針に従ってください。

認証については、大学のSSO、出版社のログイン、Zoteroアカウント、Overleafアカウントを区別します。ログイン画面だけDIRECT、ログイン後のAPI通信だけPROXYという分裂が起きると、認証成功後に再びログインを求められることがあります。認証ドメインとサービス本体の経路が同じポリシーで処理されているかをログで確認し、Cookieやトークンを不用意に削除する前に、まず経路を揃えてください。

実際に設定する手順

1. 現状を保存する：Clashの現在のプロファイル、DNS設定、システムプロキシ状態をバックアップし、大学VPNや他のプロキシを一時的に確認します。
2. ブラウザで基準を作る：学術検索、出版社の論文ページ、Overleafのプロジェクトを順番に開き、正常に動くURLと失敗するURLを記録します。
3. Zoteroの同期を単独で実行する：他のダウンロードを止め、認証、メタデータ、添付ファイルの各段階でClashログに出るホストを記録します。
4. Overleafの編集を確認する：小さなテストプロジェクトを開き、文字を編集、保存、コンパイル、PDFプレビューの更新まで行います。長時間接続が切れないかも確認します。
5. 必要なルールだけ追加する：ログで確認したドメインをDOMAINまたはDOMAIN-SUFFIXとして追加し、研究用ポリシーグループへ割り当てます。MATCHより上に置くことを忘れないでください。
6. ターミナルを別に検証する：環境変数を設定した新しいシェルから、Git、文献取得スクリプト、Overleaf CLIなどを試します。GUIで成功してもCLIが同じ経路を使うとは限りません。
7. 一度に一つだけ変更する：DNS、ノード、ルール、TUNを同時に変更せず、各変更後に同じテストを繰り返します。これにより、改善した設定を後から再現できます。

ログとコマンドで結果を検証する

接続確認では、画面が表示されたかだけでなく、Clashがどのポリシーへ通信を送ったかを確認します。Clashのログでドメイン、ルール名、ポリシーグループ、接続時間を見て、期待した経路と一致しているかを調べます。特定の接続だけがDIRECTになっている場合、上位ルールの不足、ドメイン表記の違い、DNS解決後のIPルールへのフォールバックなどが考えられます。

コマンドラインでは、まずプロキシを明示した簡単なHTTPSリクエストを実行します。認証が必要なサービスへ無理にアクセスするのではなく、利用が許可された公開エンドポイントや自分の研究機関が案内する確認URLを使ってください。curl -vの出力では、名前解決、CONNECT、TLSハンドシェイク、HTTP応答を分けて読みます。403や401は認証や権限の問題であり、TLS接続そのものが成功している場合があります。

# Use an approved public endpoint for a connectivity check
curl -vI https://example.org

Zoteroの場合は、同期ボタンを押した時刻を記録してからログを確認します。Overleafの場合は、ページを開いた直後だけでなく、編集、保存、コンパイル、PDF表示の各時点で確認します。長時間接続の問題は、最初の接続テストだけでは再現できないためです。再現条件を「自宅Wi-Fi」「大学VPN接続中」「特定ノード」「一定時間編集後」のように具体化すると、ノード障害とルール設計の問題を分離しやすくなります。

よくある失敗と修正方針

• ブラウザだけ成功する：システムプロキシは動いているが、ZoteroやCLIがその設定を読んでいない可能性があります。アプリ側設定と環境変数を確認します。
• Zoteroのメタデータだけ同期する：添付ファイルの保存先が別ホストになっていないか、WebDAVの認証とルールを確認します。
• Overleafの画面が途中で切れる：長時間接続に使われるホストが別ルートへ流れていないか、自動ノード切り替えやVPN競合がないかを見ます。
• 大学サイトまで遅くなった：広すぎるsuffixルールを縮小し、学内サービスを公式の経路へ戻します。
• 設定変更後に原因が分からない：複数の変更を元に戻し、一つずつ同じテストを行います。バックアップしたプロファイルとの差分も有効です。

研究環境として安全に維持する

研究用のClash設定は、一度動けば終わりではありません。出版社のドメイン変更、Overleafの配信基盤変更、Zoteroの同期仕様変更、大学VPNの更新などにより、数か月後に挙動が変わることがあります。設定ファイルに変更理由、確認日、対象サービス、利用したポリシーグループをコメントとして残すと、将来の再現性が高まります。

購読設定やプロファイルには、ノード情報、更新URL、認証情報が含まれる場合があります。研究室の共有フォルダやGitリポジトリへそのまま保存せず、秘密情報と一般ルールを分離してください。バックアップを作る場合も、アクセス権を限定し、不要になったURLや古いトークンを削除します。

さらに、論文執筆の締切直前に大きな設定変更をしないことも重要です。普段の作業用プロファイル、学外アクセス用プロファイル、大学VPN併用時のプロファイルを分け、どの状況でどれを使うかを決めておくと、障害時に安全な構成へ戻せます。TUNはプロキシ非対応アプリを救える一方、大学VPNや他の仮想ネットワークと競合しやすいため、必要性を確認してから限定的に利用してください。

まとめ：研究作業に合わせて小さく分流する

研究者向けのClash設定で大切なのは、学術検索、Zotero同期、Overleaf編集を同じ通信として扱わないことです。まず現在の経路を記録し、ブラウザ、Zotero、Overleaf、CLIを分けて検証します。そのうえでClashのログに現れたホストを根拠に、必要なルールだけを追加します。大学ポータルや研究室内サービスは公式のDIRECTまたは大学VPNへ残し、外部サービスは用途別のポリシーグループへ送ると、速度と安定性のバランスを取りやすくなります。

単純なVPNアプリや用途別の小さなプロキシツールは、初回設定が簡単な反面、アプリごとの経路確認、複数OSでのプロファイル共有、ルールの優先順位、DNSの切り分けが難しくなることがあります。一方、Clashはルール、ログ、ポリシーグループ、システムプロキシ、TUNを段階的に組み合わせられ、Zoteroだけ、Overleafだけ、または学術サイトだけを個別に調整できます。研究ワークフローを壊さずに接続経路を説明可能な形で管理したい場合は、まず小さなテストプロファイルからClashを導入してみるとよいでしょう。

Clash を無料でダウンロードして、快適なネット体験を →