研究人員用 v2rayN 打造學術檢索與文獻管理代理方案

研究人員每天處理的網路流量，通常同時包含學術檢索、出版社頁面、文獻管理同步、雲端儲存與協作編輯。這些服務的網域、連線方式和登入狀態並不完全相同，如果把所有流量一律交給代理，可能增加延遲、觸發額外驗證，甚至讓校園內網與圖書館資源無法正常使用。較穩妥的做法，是先按工作流程整理服務，再在 v2rayN 中以網域、連接埠和應用需求安排分流。

本文以 Windows 桌面端的 v2rayN 為例，說明如何規劃 Google Scholar 檢索、出版社與預印本網站、Zotero 同步，以及 Overleaf 編輯工作的代理路徑。文中的網域只是規則示例，實際使用時應以所在學校、研究機構或服務提供者公布的正式網域為準。代理只能改善連線路徑，不能取代合法的機構訂閱、資料庫授權或出版社存取權限。

先把學術工作拆成四段連線流程

研究人員常把「查論文」理解成單一任務，但實際上至少包含四種不同請求。第一種是搜尋與發現，例如 Google Scholar、學術搜尋入口和作者頁面；第二種是內容取得，例如出版社網站、預印本服務與期刊 PDF；第三種是文獻管理，例如 Zotero 的同步、附件儲存和引用資料更新；第四種是協作編輯，例如 Overleaf 專案頁面、編譯服務與團隊登入。這些請求即使由同一個瀏覽器發起，也可能使用不同的網域和第三方服務。

分流的第一個原則是不要只依網站首頁判斷。Google Scholar 的搜尋頁面可能會跳轉到登入、引用匯出或出版社頁面；出版社則可能使用多個內容傳遞網域提供 CSS、PDF 和圖片；Zotero 同步也不等同於瀏覽器開啟 Zotero 網站。若只把 scholar.google.com 加入規則，並不能保證所有後續請求都會沿用同一條路徑。

1. 檢索：搜尋關鍵字、查看引用關係與追蹤作者頁面。
2. 取得：開啟 DOI 轉址、出版社頁面或合法可下載的全文。
3. 同步：更新 Zotero 書目資料、附件與群組資料。
4. 協作：在 Overleaf 編輯、編譯、預覽並分享專案。

接著要決定哪些流量直連、哪些流量代理。若所在地網路可穩定開啟校園圖書館、機構登入和本地服務，這些流量通常應保留直連，避免代理節點改變來源位置而觸發額外驗證。對於在目前網路中經常載入失敗、DNS 解析不穩定或需要特定出口位置的學術服務，才考慮交給代理出站。

在 v2rayN 中設計代理與直連出站

v2rayN 的主介面負責管理伺服器、訂閱分組和核心啟動；具體的路由判斷通常由 Xray 核心執行。開始設定前，先確認目前使用的核心類型、核心版本和本機代理連接埠。Windows 桌面端常見的 HTTP 代理連接埠可能是 10809，SOCKS 連接埠可能是 10808，但實際數值取決於目前設定，不能直接套用其他裝置的數值。

在 v2rayN 中可先由「設定」→「參數設定」確認核心類型、系統代理和本機監聽連接埠，再到路由或分流相關頁面確認規則模式。不同版本的中文選單名稱可能略有差異；若找不到「路由設定」，可查看「參數設定」中的路由、分流或 Xray 設定入口。最重要的是確認修改後，實際啟動的是同一個核心，而不是只編輯了未被載入的設定檔。

規則順序十分重要。區域網路和機構服務的例外應放在寬泛的代理規則之前；若最後使用「其餘流量全部代理」作為兜底，必須確認 DNS、更新服務和內部資源不會被錯誤接管。對於網域規則，可使用完整網域、網域後綴或 geosite 類別，但不要把不存在於實際請求中的主網域當成萬用匹配條件。

Google Scholar 與全文網站的分流方法

Google Scholar 的主要用途是發現文獻、查看引用和尋找不同版本。搜尋結果中的「所有版本」、DOI 連結或出版社按鈕，經常會把瀏覽器帶到另一個網域。這表示 Scholar 本身可以正常開啟，但點擊全文後仍可能失敗。排查時應把搜尋頁、轉址頁和最終全文頁分開測試，記錄每一步的網址，而不是只檢查瀏覽器標籤上的網站名稱。

如果 Scholar 搜尋頁面載入很慢，可先在 v2rayN 中選取一個延遲穩定的節點，開啟系統代理，再以無痕視窗測試搜尋。不要在短時間內連續重新整理或大量自動化查詢，因為 Google Scholar 可能根據請求頻率、Cookie、登入狀態與來源網路觸發驗證。遇到驗證頁時，先停止重試，確認研究用途符合服務規則，並考慮使用學校提供的學術入口或圖書館代理。

出版社與預印本服務則要注意 PDF 下載的實際網域。有些網站的文章頁與 PDF 由同一主網域提供，有些會使用獨立的靜態內容網域。可以開啟 Xray 日誌，觀察瀏覽文章頁和下載 PDF 時出現的目標主機，再只把確實需要的網域加入規則。若規則過度使用通配字串，可能把同一服務的分析、廣告或第三方登入請求一併送進代理，增加問題範圍。

DNS 也會影響學術網站的分流。若核心只看到 IP，而設定依賴網域判斷，原本準備好的網域規則可能不會命中。使用 TUN 模式時，應確認 DNS 請求確實由核心接管，並檢查 domainStrategy、FakeDNS 或嗅探設定是否與目前的路由方式一致。若沒有明確需求，不要為了「看起來更完整」同時改動 DNS、FakeDNS、嗅探和路由兜底；一次只變更一個項目比較容易定位結果。

安排 Zotero 同步與 Overleaf 協作

Zotero 的使用通常分成書目資料同步與附件同步兩部分。書目資料量相對較小，附件則可能包含多個 PDF、掃描檔與筆記。兩者的登入狀態、請求目標和傳輸時間不一定相同，因此「Zotero 可以開啟」不代表「同步一定成功」。開始測試前，先在 Zotero 的同步設定中確認帳戶狀態、同步範圍和儲存空間，再查看 v2rayN 是否有對應的連線記錄。

若書目資料能同步但附件長時間停留在佇列，可能是附件儲存服務的網域沒有命中相同規則，也可能是單一節點對長時間 HTTPS 傳輸不穩定。可以先只同步一筆小型附件，觀察日誌和實際耗時，再測試較大的檔案。不要一次刪除本機資料庫或重建整個 Zotero 資料夾，因為這會把可逆的連線問題變成資料恢復問題。

Overleaf 也不只是開啟編輯器頁面。載入專案時可能涉及登入、專案資料、編譯請求、PDF 預覽、圖片資源和團隊協作通知。若編輯器可以開啟但編譯一直等待，應分別檢查專案頁面、編譯服務與預覽資源。若編譯服務在機構網路中本來就可用，將它強制走遠端代理反而可能造成登入 Cookie 或來源網路不一致。

對協作平台而言，穩定性通常比單次速度更重要。可以在同一節點下連續完成開啟專案、修改一行文字、啟動編譯和下載預覽四項測試，記錄是否出現重新登入、WebSocket 斷線或編譯結果延遲。若只有即時協作功能不穩，查看核心日誌中的長連線錯誤，不要先把所有 Overleaf 相關網域無差別加入代理。

用日誌與分段測試維持穩定

完成設定後，不要只用「網頁能開」作為通過標準。至少建立一份簡單測試表，記錄測試日期、使用節點、目標網域、測試動作和結果。2026 年的研究工作流可能同時使用瀏覽器、Zotero 和 Overleaf 桌面或網頁介面；每次更新 v2rayN、Xray 核心、訂閱內容或服務端規則後，都應重新確認主要流程。

遇到問題時，先確認 v2rayN 是否真的啟用了系統代理或 TUN，再查看核心是否正在執行。接著檢查目標網域是否解析、規則是否命中、出站是否選對，以及節點遠端連接埠是否可達。若日誌出現 connection refused、i/o timeout 或 failed to resolve host，它們分別指向拒絕連線、等待逾時和解析失敗等不同層級，不應全部歸類為「節點速度慢」。

最後，保留一份可回復的設定。每次只調整一組規則，修改前備份目前可用版本，並在更新訂閱後重新確認活動伺服器。當 Scholar、Zotero 或 Overleaf 的服務端網域改變時，優先從日誌找出實際目標，再更新分流規則；不要盲目擴大匹配範圍。這樣建立的代理方案不只較順暢，也能在研究平台改版、節點更換或核心升級後快速恢復。