研究者向けV2Ray設定術｜Google ScholarとZoteroを快適化

研究者のネットワーク環境では、一般的なWeb閲覧だけでなく、Google Scholarでの文献検索、出版社サイトからの論文PDF取得、Zoteroのメタデータ取得と同期、Overleafでの共同執筆など、性質の異なる通信を同時に扱います。すべてを単純にグローバルプロキシへ送ると、国内から直接アクセスした方が速いサービスまで遠回りになり、逆に学術出版社や文献データベースだけを直通にすると、検索結果は表示されてもPDF取得やAPI通信でタイムアウトすることがあります。

この記事では、v2rayNとv2rayNGを使って研究用途の通信を整理する方法を説明します。Google Scholar、出版社の論文ページ、Crossrefなどの文献関連サービス、Zoteroの同期、Overleafの編集画面を同じ扱いにせず、ドメイン、アプリ、ポート、DNS、ルーティングの順に確認します。特定のサイトを必ずプロキシ経由にすることを目的とせず、所属機関や契約サービスの利用規約、研究データの機密性、アクセス元の要件を確認したうえで設定してください。

研究用通信を用途別に分ける理由

研究者向けの通信を一つのルールで処理すると、問題が発生したときに原因を特定しにくくなります。Google Scholarの検索画面は開くのに検索候補や引用情報が読み込まれない場合、ブラウザー本体ではなく、別ドメインのAPIや静的コンテンツが失敗している可能性があります。出版社のページでも、HTMLは表示される一方、PDF配信サーバー、認証サーバー、Cookie検証用のホストが別経路になることがあります。

Zoteroは、文献情報の取得、添付PDFの保存、WebDAVまたはZoteroの同期、アカウント認証など、複数の通信を行います。文献情報の取得だけなら直通で成功しても、添付ファイルの同期は大容量HTTPS通信として別の制限を受けることがあります。Overleafも、画面表示、プロジェクトのWebSocket接続、画像やフォントなどの静的リソース、コンパイル結果の取得を分けて考える必要があります。

最初は「研究関連はすべてプロキシ」という広いルールから始めるより、利用頻度の高いドメインだけを明示し、その他は既存のルールに任せる方が安全です。ルールは上から評価されるため、LAN、localhost、所属機関内のアドレス、信頼できる国内サービスなどの例外を先に置き、その後に学術サイトのプロキシルールを配置します。意図しない全通信の転送を避けるため、設定を変更した日時と対象ドメインを記録しておくと、後から戻しやすくなります。

学術サイトのルーティングを設計する

ルーティング対象を作るときは、画面に表示されたURLだけを登録しないことが重要です。Google Scholarの検索、出版社の論文ページ、PDFの配信、文献メタデータ取得は、それぞれ異なるホスト名へ接続する場合があります。まずブラウザーの開発者ツールやv2rayNのログで、接続先のホスト名と失敗時刻を確認し、実際に必要なドメインだけを追加します。ワイルドカードを広く設定する場合も、対象の範囲を記録し、動作確認後に不要な規則を削除してください。

ルールの順序は、例外、研究関連の明示ルール、地域や用途に応じた既存ルール、最後の既定ルートという構成にすると管理しやすくなります。Google Scholarだけをプロキシにしたつもりでも、検索結果から開いた出版社ページが別ルールに一致して直通になることがあります。反対に、Overleafのような共同編集サービスをドメイン単位で広く指定すると、不要な静的コンテンツまで遠回りになり、表示速度が落ちることがあります。

v2rayNとv2rayNGで実際に設定する

設定前に、正常に動作するVMessまたはVLESSノードを1つ選び、ブラウザーで通常のWebページを開けることを確認します。研究用途のルールを追加する前にノード自体を検証しておくと、ルーティングの問題とサーバー側の問題を分けられます。v2rayNでは、ローカルのSOCKSポートを10808、HTTPポートを10809とする構成が一般的です。別の番号を使う場合は、クライアント、システムプロキシ、アプリ側の設定を同じ番号にそろえてください。

1. ノードを確認する

   v2rayNまたはv2rayNGでサブスクリプションを更新し、接続テスト済みのノードを選択します。Xrayコアを使う場合は、コアの起動ログにエラーがないことを確認してから次へ進みます。

2. 経路を選択する

   v2rayNのメイン画面またはトレイメニューで、まずルールベースのルーティングを選びます。最初からグローバルにせず、LANと通常利用の例外が保たれているか確認します。

3. 学術ルールを追加する

   「設定」→「ルーティング設定」または使用中のルール編集画面を開き、Google Scholar、出版社、Zotero、Overleafで実際に確認したドメインを追加します。ルールの順序を保存し、重複する既存ルールがないか確認します。

4. Androidを確認する

   v2rayNGではプロファイルを選択し、VPN接続を開始します。「設定」内のアプリ別ルーティングを使う場合、Zoteroなど必要なアプリが除外リストに入っていないか確認します。省電力設定によるバックグラウンド停止も確認してください。

5. 用途ごとに試す

   検索、PDF表示、Zotero同期、Overleaf保存の順に一つずつ試します。各操作の時刻、使用ノード、ログの宛先、成功または失敗を記録すると、複数の原因を同時に変更せずに済みます。

Zoteroのデスクトップアプリがシステムプロキシを自動認識しない場合は、アプリのネットワーク設定を確認します。HTTPプロキシとSOCKSプロキシのどちらを利用できるかは、アプリのバージョンやOSによって異なるため、使える方式を選び、ホストを 127.0.0.1、ポートをv2rayNの待受ポートに設定します。設定後は小さなライブラリで同期を試し、大量の添付ファイルをいきなり同期しないでください。

Overleafでは、編集画面が開くことだけで成功と判断しません。短い変更を保存し、別のブラウザーまたは共同編集者側で反映を確認し、1回のコンパイルを完了させます。WebSocketや長時間HTTPS接続が途中で切れる場合は、速度測定値よりパケットロスと接続の継続時間を優先してノードを選びます。

DNSとアプリ別プロキシを確認する

学術サイトへの接続が不安定なとき、ドメインルールだけを変更してもDNSが直通のままだと、名前解決の結果や接続先が一貫しないことがあります。v2rayNではDNS設定、ルーティング、TUNをそれぞれ別の機能として確認します。システムプロキシだけを使う場合、システムプロキシを参照しないZoteroや補助ツールの通信は取り込まれません。TUNを使う場合でも、取り込んだ通信が最終的に直通になるルールがあれば、期待した経路にはなりません。

• ブラウザー：セキュアDNSを有効にしている場合、ブラウザー独自のDoH通信がクライアントの想定外になることがあります。検証時だけ一時的に設定を固定し、変更前後を比較します。
• Zotero：アプリ内プロキシ、OSのプロキシ、TUNのいずれが実際に有効かを確認します。同期ログに認証、TLS、タイムアウトのどれが出ているかで調査の方向が変わります。
• Overleaf：ページ、保存、コンパイル結果を別々に検証します。画面が見えていても、保存リクエストだけ失敗していることがあります。
• v2rayNG：VPN接続中にアプリ別ルーティングを変更した場合は、いったんVPNを停止して再接続します。除外アプリと常時VPN設定が競合していないかも確認します。

研究ワークフローを壊さず検証する

検証は、同じノードと同じネットワークで行い、変更した項目を一つに絞ります。最初にGoogle Scholarでキーワード検索を実施し、検索結果から論文ページを開きます。次にPDFを表示して、ページ送り、ファイル保存、別タブでの再読み込みを確認します。その後、Zoteroの文献情報取得と小規模な同期を試し、最後にOverleafで短い編集、保存、コンパイルを行います。この順番なら、基本的なHTTPS、ファイル取得、アプリ通信、長時間接続を段階的に確認できます。

ログには個人情報や認証情報が含まれることがあるため、共有する場合はメールアドレス、トークン、UUID、完全なURL、機関内ホスト名を削除します。接続先ドメイン、発生時刻、エラー種別、使用したコア、ローカルポートだけでも、初期の切り分けには役立ちます。設定を変更する前に現在のルールをエクスポートまたはコピーしておけば、研究作業の途中で問題が増えた場合にもすぐに元へ戻せます。

最終的な目標は、すべての通信をプロキシに送ることではありません。Google Scholarの検索、必要な論文PDF、Zoteroの同期、Overleafの保存が、それぞれ安定した経路で完了し、不要なサイトや機関内サービスを無駄に遠回りさせない状態です。利用するサービスの規約と所属機関の方針を守りながら、接続経路、DNS、アプリ設定、ログの順に確認すれば、ノードを頻繁に交換するより再現性の高い研究環境を作れます。