研究用サービスは、ドメイン単位で経路を分ける
Google Scholar、arXiv、IEEE Xplore、Overleaf、Zoteroをすべて同じノードへ送る必要はありません。まずClashをRuleモードにし、研究用サービスの通信を専用の選択グループへ送ります。接続が安定したノードを選んだうえで、Connections（接続）画面から実際に使われたルールと経路を確認してください。サイトを開けることだけでなく、検索結果の表示、PDFの取得、文書の保存や同期まで試すと、問題の切り分けがしやすくなります。
Clashはクライアント画面を提供し、Clash Meta（現名称：mihomo）などのコアが設定を読み込んで通信を処理します。設定項目の場所や対応機能はクライアントとコアのバージョンで異なります。以下のYAMLはmihomo向けの部分例です。ノード、完全なDNS設定、ルールプロバイダーは含まれていないため、そのまま使える接続設定ではありません。実際の設定へ追加する前に、既存のルール順、グループ名、コアの検証結果を確認してください。
「研究用サービス」として一括りにしても、各サービスが使うホスト名は異なります。Google Scholarの検索ページが表示されても、Googleの別サービスやPDF配信先が同じ経路になるとは限りません。最初から大きなドメイン範囲をまとめて振り分けるより、接続ログで実際の宛先を確認し、必要なホストだけを追加するほうが影響範囲を抑えられます。
研究用のプロキシグループを用意する
既存のサブスクリプションに使いやすい選択グループがあれば、それを利用できます。なければ、最初は select 型のグループを追加し、接続の検証中は同じノードを手動で選びます。自動選択グループは測定結果に応じてノードが切り替わることがあります。ログインや文書編集の途中で出口が変わると、サービス側のセッション確認や再ログインが発生する場合があるため、原因を切り分ける間は経路を固定すると便利です。
proxy-groups:
- name: Academic
type: select
proxies:
- Node-A
- Node-B
- DIRECT
rules:
- DOMAIN-SUFFIX,scholar.google.com,Academic
- DOMAIN-SUFFIX,arxiv.org,Academic
- DOMAIN-SUFFIX,ieee.org,Academic
- DOMAIN-SUFFIX,overleaf.com,Academic
- DOMAIN-SUFFIX,zotero.org,Academic
- MATCH,その他の選択グループこの例の Node-A、Node-B、グループ名は説明用です。実際のノード名に置き換え、参照先のグループが設定内に存在することを確認してください。既存の rules がある場合は、例のルールだけを末尾へ無条件に追加しないでください。Clashのルールは上から評価され、先に一致したルールが使われます。ドメイン単位のルールは一般に MATCH などの包括的なルールより前に置きますが、すでに一致するルールがあれば、その順序も含めて見直します。
| 対象 | 確認するホストの例 | 注意点 |
|---|---|---|
| Google Scholar | scholar.google.com | 検索ページと、結果に含まれる出版社や機関リポジトリは別のドメインになることがあります。 |
| arXiv | arxiv.org | 論文のHTML、PDF、APIの各操作を分けて確認します。実際の配信先が異なる場合は接続記録を見ます。 |
| IEEE Xplore | ieee.org | ログイン、検索、本文表示、機関認証が別のホストへ移ることがあります。 |
| Overleaf | overleaf.com | ページ表示だけでなく、編集画面の接続維持と保存も確認します。 |
| Zotero | zotero.org | アカウント同期と、WebDAVを使った添付ファイル同期は別の接続先になる場合があります。 |
DOMAIN-SUFFIX,ieee.org のような指定は、そのドメイン配下を広く対象にします。意図しない通信まで同じグループに入る可能性があるため、より限定した指定が必要なら、接続履歴で実際のホスト名を確認して DOMAIN ルールを使う方法もあります。逆に、未確認の関連ドメインを推測で大量に追加すると、原因を追いにくくなります。まず主要ページを試し、失敗した操作の時刻と宛先を照合してから、必要なルールを一つずつ追加してください。
Scholar・arXiv・IEEE Xploreを順番に検証
ブラウザーで開けるかだけでは、通信経路が意図どおりとは限りません。クライアントのProxies（プロキシ）で Academic にノードを選び、Connections（接続）画面を開いてから、サービスを新しいタブで操作します。ドメイン、適用されたルール、選択グループ、最終ノードを確認してください。接続が表示されないときは、キャッシュ済みページや既存の長時間接続を避けるため、テスト用タブを閉じて再度開きます。
- Google Scholarで検索を実行し、検索結果ページの表示に加えて、論文のリンクを一つ開きます。リンク先が出版社や大学のリポジトリなら、そのホストも記録します。
- arXivで論文の要約ページを開き、HTML版とPDF版をそれぞれ試します。片方だけ失敗した場合は、ページのドメインだけで判断せず、失敗したリクエストの宛先をConnectionsで確認します。
- IEEE Xploreでは検索結果の表示と論文ページへの遷移を確認します。本文へのアクセス可否は契約、機関認証、論文の公開条件にも左右されるため、Clashの経路だけで利用権限を判断しないでください。
- 同じ操作を別のノードでも行う場合は、ルールと対象ページを変えず、一度に一つの条件だけを変更します。接続できることと、サービスが許可する範囲で閲覧できることを分けて記録します。
ルールが DIRECT になっている場合は、Ruleモードか、より上にあるルールが一致していないかを確認します。期待したプロキシグループが表示されているのに接続が失敗する場合は、ノードの状態、名前解決、リモート側の接続状況、サービス側の応答を確認してください。ノードの遅延テストが成功しても、特定のサイトや機関認証の通信が必ず成功するとは限りません。
ターミナルから同じ接続を試す場合、システムプロキシを参照しないアプリもあるため、プロキシを明示して比較できます。以下はHTTPまたは混合ポートが 7890 の場合の例です。実際の待ち受け設定に合わせてください。
curl -I -x http://127.0.0.1:7890 https://arxiv.org応答コードだけでページ全体の利用可否を断定しないでください。リダイレクト、認証、利用制限、サイト側の応答によって結果は異なります。通常のブラウザーだけが失敗するなら、ブラウザー拡張機能、PAC、個別プロキシ設定を確認します。コマンドだけが失敗する場合は、指定したポートがHTTPプロキシを受け付けるか、ターミナルが別の環境変数を使っていないかを確認してください。
Zotero同期とOverleafの接続を切り分ける
Zoteroはライブラリ同期と添付ファイル同期を分けて確認
Zoteroで文献情報は同期されるのにPDFが別の端末へ届かない場合、すべてを同じ「プロキシ不調」と扱わないでください。Zoteroアプリの設定で同期状態とエラー表示を確認し、ライブラリのメタデータと添付ファイルがどの方式で同期されているかを分けて記録します。Zotero Storageを使う場合と、WebDAVサーバーを使う場合では接続先が異なります。WebDAVを設定しているなら、実際のサーバー名を確認し、そのホストがどのルールに一致したかをConnectionsで調べます。
- まずZoteroアカウントへサインインできるか確認し、アプリに表示される同期エラーと時刻を控えます。
- 小さなテスト項目を一つ作成し、文献情報の同期と添付ファイルの同期を別々に実行します。
- WebDAV利用時は、サーバーのURL、認証情報、同期設定を確認します。認証情報をClashの共有設定や公開ログへ記載しないでください。
- 同一端末上でブラウザーのWebDAVサイトが開くことだけでは、Zoteroアプリの同期が成功する証明になりません。アプリ側のログと接続記録を照合します。
Overleafはページ表示と編集・保存を別々に試す
Overleafのトップページやプロジェクト一覧が表示されても、編集画面の更新や保存が安定するとは限りません。プロジェクトを開き、短い一時変更を加えて保存状態を確認し、テスト後に元へ戻します。接続が切れる場合は、Connectionsに関連する通信が現れているか、ルールが途中で別グループへ振り分けられていないか、ノードが自動切り替えされていないかを確認してください。ブラウザーの開発者ツールにエラーが出る場合は、個人情報や非公開原稿を含まない範囲で、エラーの種類と発生時刻だけを記録します。
Overleafの動作はネットワークだけでなく、ブラウザー拡張機能、Cookie設定、アカウント権限、サービス側の状態にも左右されます。問題が続く場合は、拡張機能を一時的に止めた新しいブラウザープロファイルで比較し、同時に別の設定やノードを変更しないようにします。研究機関のアカウントや共有プロジェクトを使っている場合は、組織が定めた接続・データ保護の条件を確認してください。
DNS・プライバシー・設定変更を確認する
DNSの設定を変えた直後にサイトが開かなくなった場合は、まずその変更を戻せるように保存内容を確認します。Fake-IP、DNSの上流サーバー、ルールによるDNS処理は、コアのバージョンや既存設定によって挙動が異なります。研究用ドメインだけの問題か、ほかのドメインにも影響するかを比べ、ConnectionsとLogsの時刻を合わせて調べます。検証のために端末全体のDNS保護を無効にしたり、大学ネットワークの設定を削除したりする必要はありません。
| 症状 | まず見る画面・項目 | 次の確認 |
|---|---|---|
| ページに接続記録がない | ブラウザー設定、拡張機能、キャッシュ、システムプロキシ | 新しいタブで再試行し、プロキシを明示した接続と比較する |
| 記録はあるがDIRECTに一致 | Ruleモード、ルールの順序、対象ホスト | 先に一致したルールを確認し、必要なホストだけを適切な位置へ追加する |
| ノード経由だがサイトが失敗 | ノード状態、DNS、ログの具体的なエラー | 別ノードと同じ操作を比較し、サービスや機関のアクセス条件も確認する |
| Zoteroの文献情報だけ同期される | 添付ファイルの同期方式、WebDAV設定 | 実際の同期先ホストとアプリ側の同期エラーを確認する |
| Overleafで編集が切れる | Connections、ノードの切り替え、ブラウザー拡張機能 | 同じノードで保存を試し、ブラウザー側の接続エラーと比較する |
研究データの機密性が重要な場合は、経路を変える前に所属機関の情報セキュリティ方針を確認してください。Clashのログにはアクセス先のホスト名や接続情報が記録されることがあります。調査後は必要以上に詳細なログを保持せず、共有するときはアカウント名、トークン、論文の非公開URL、個人を識別できる情報を除いてください。プロキシ利用によって、機関の契約条件やサービスの利用条件が変わるわけではありません。
安定運用の基本は、Ruleモードで必要なドメインだけを振り分け、最初は手動選択グループで経路を固定し、検索・PDF・同期・編集を個別に検証することです。設定変更後に問題が増えたら、追加したルールを一つずつ戻して比較します。サブスクリプション全体の書き換え、過度に広いGoogle関連ドメインの一括振り分け、複数のVPNやTUNの同時有効化は、原因を特定しにくくするため避けてください。