前言：研究工作流為什麼需要穩定分流
對研究人員而言，網路問題往往不是單純的「網頁打不開」。你可能正在 Google Scholar 搜尋關鍵文獻，點擊結果後卻長時間載入；也可能在 Zotero Connector 儲存論文時，瀏覽器已經顯示完成，但附件與書目資料沒有同步；到了寫作階段，Overleaf 編譯卡在套件下載，或 IEEE Xplore 的全文頁面因連線不穩而反覆逾時。這些中斷會把原本連續的閱讀、整理與寫作節奏切碎。
Clash 的價值在於把不同服務的流量分開處理：需要穩定跨境連線的學術平台走可靠的代理策略，校園內網、資料庫入口與本地服務則維持直連。這種做法比長時間開啟全域代理更容易控制，也能減少不必要的延遲、驗證風險與流量消耗。
本文目標
建立一套適合研究情境的 Clash 分流思路，涵蓋 Google Scholar、Zotero、Overleaf 與 IEEE Xplore，並說明如何測試 DNS、節點與同步問題。
1先拆解學術工具的連線需求
在編寫規則之前，先理解每個工具的工作方式。Google Scholar 主要是搜尋與結果跳轉，通常需要穩定解析 Google 相關網域；Zotero 桌面程式除了登入與同步，還會連線至儲存服務，瀏覽器 Connector 則依賴目前開啟的論文頁面；Overleaf 同時包含網頁編輯器、即時同步、Git 或外部整合，以及編譯時的套件與圖片請求；IEEE Xplore 則常見登入、搜尋、PDF 預覽與引用匯出等不同請求。
因此，不建議只寫一條籠統的 DOMAIN-KEYWORD,google,PROXY 規則。過度寬泛的規則可能讓 Google Drive、YouTube 或其他無關服務一起切換節點，也可能把校園 Google Workspace 的內部流量導向不必要的路徑。比較穩妥的方式是使用 DOMAIN-SUFFIX、DOMAIN 與既有規則集逐步縮小範圍，並把學術服務放進獨立策略組。
| 服務 | 主要需求 | 建議策略 | 常見檢查點 |
|---|---|---|---|
| Google Scholar | 搜尋、結果跳轉、引用匯出 | 穩定代理節點 | 解析速度、驗證頁面、跳轉是否逾時 |
| Zotero | 帳號登入、書目同步、附件同步 | 固定節點或穩定代理 | 同步佇列、附件下載、Connector 回應 |
| Overleaf | 編輯器、編譯、Git 與套件請求 | 低延遲且不頻繁切換 | WebSocket、編譯逾時、專案同步 |
| IEEE Xplore | 搜尋、登入、PDF 與引用下載 | 依所在地與機構政策選擇 | 校園登入、全文權限、PDF 連線 |
學術存取提醒
Clash 只能改善連線路徑，不能取代學校訂閱、VPN、圖書館代理或出版商授權。請依研究機構的資訊安全政策使用，勿以代理繞過付費牆、登入限制或地區服務條款。
2動手配置：建立研究服務專用分流
以下以支援 Mihomo 的 Clash Verge Rev 為例。Clash Verge、Clash for Windows 或其他客戶端的選單名稱可能不同，但核心概念相同：先備份目前配置，再新增代理組與規則，最後重新載入設定。若你使用的是學校提供的配置，請先確認是否允許自行修改。
- 開啟 Clash Verge Rev，確認訂閱已更新，並在「代理」頁面挑選一個延遲合理、連線穩定的節點。
- 建立名為
ACADEMIC的策略組。初期建議使用手動選擇，避免自動測速頻繁切換 IP。 - 在 YAML 的
proxy-groups與rules區塊中加入研究服務規則，並讓規則排在一般兜底規則之前。 - 重新載入配置後，先用瀏覽器測試 Scholar 與 IEEE Xplore，再測試 Zotero 同步和 Overleaf 編譯。
上面的規則是起點，不是對所有環境都適用的固定清單。部分服務可能使用額外的 CDN、登入或附件網域，遇到頁面能開但功能不完整時，應從 Clash 的連線記錄查看實際請求，再精確補充規則。不要一開始就把整個 google.com 或所有海外流量納入代理，否則很難判斷究竟是哪個網域造成問題。
規則順序與策略組設計
Clash 通常按照規則由上至下比對，先命中的規則會決定流量方向。因此，學術服務規則必須放在 GEOIP、GEOSITE 或 MATCH 等寬泛規則之前。若配置中已有名為「代理」「國外」或「自動選擇」的策略組，可以直接重用；但研究工作不建議完全依賴自動切換，因為 Zotero 同步或 Overleaf WebSocket 連線期間換節點，可能造成重新登入或編譯中斷。
3DNS、TUN 與四個工具的實際調整
先處理 DNS 與 TUN 模式
如果網域解析仍由不穩定或受干擾的本地 DNS 完成，即使代理節點本身正常，Scholar、Overleaf 或 IEEE Xplore 仍可能出現間歇性逾時。支援 Mihomo 的客戶端可以在「DNS」設定中啟用內置 DNS，並依你的網路環境選擇可信任的 DoH 或 DoT 服務。若開啟 TUN 模式，請同時確認「自動設定系統代理」與 DNS 劫持選項沒有互相衝突。
建議一次只改一個設定。先記錄未開 TUN 時的結果，再開啟 TUN 測試；若瀏覽器正常但校園印表機、內網入口或資料庫代理失效，可以為校園網域加入 DIRECT 規則，或暫時關閉 TUN 以確認問題來源。研究資料常涉及未公開稿件與個人帳號，請避免使用來路不明的 DNS、公共節點或自動注入腳本。
Google Scholar 與 Zotero 的連續工作流
在 Scholar 搜尋到文獻後，先觀察結果頁與出版商頁面是否都能穩定開啟，再按 Zotero Connector 圖示儲存。若 Connector 顯示成功但 Zotero 沒有附件，可能是出版商頁面需要再次登入、PDF 位址使用不同網域，或瀏覽器擴充功能沒有權限。此時可查看 Clash 連線記錄，找出被 DIRECT 或錯誤策略處理的網域。
Zotero 桌面程式的同步則應使用固定策略。大量附件同步前，先只同步書目資料，確認登入狀態與同步佇列正常，再開啟檔案同步。若同步速度忽快忽慢，先切換到低延遲節點並等待一個完整同步週期，不要在同步中反覆切換節點。對團隊資料庫而言，也要檢查群組權限、儲存配額與機構政策，不能把所有錯誤都歸因於 Clash。
Overleaf 與 IEEE Xplore 的穩定性
Overleaf 的編輯器需要較長時間的連線，適合使用固定節點，不宜套用會頻繁探測和切換的負載均衡組。當編譯失敗時，先判斷是網路錯誤還是 LaTeX 語法錯誤：若編輯器可以輸入但編譯時套件下載失敗，應檢查相關請求是否被錯誤分流；若所有專案都無法連線，才優先檢查節點、DNS 與 TUN。
IEEE Xplore 則可能同時涉及出版商網域與學校的 Proxy 或 SSO 入口。若你在校園網路內，部分入口應維持 DIRECT；在校外使用學校提供的合法 VPN 或圖書館代理時，則應按照機構說明設定，不要任意將登入頁面與全文頁面拆到不同地區的節點。登入成功後，建議在同一個節點完成 PDF 開啟與引用匯出，避免驗證狀態因 IP 變動而失效。
4測試、排錯與長期維護
配置完成後，不要只用「首頁能否打開」作為判斷標準。可以建立一份簡單的研究連線檢查表：Google Scholar 能否完成搜尋與引用匯出；Zotero Connector 能否儲存書目，桌面程式能否完成同步；Overleaf 能否開啟專案、儲存內容並完成一次編譯；IEEE Xplore 能否在合法授權下開啟摘要、PDF 或引用資訊。每次更換訂閱、節點或客戶端版本後，重新測試一次。
| 現象 | 可能原因 | 處理順序 |
|---|---|---|
| Scholar 可開啟但搜尋逾時 | DNS、節點延遲或規則未命中 | 檢查連線記錄、DNS，再更換固定節點 |
| Connector 儲存失敗 | 出版商頁面或 PDF 網域未分流 | 查看實際請求，補充精確網域規則 |
| Zotero 一直同步中 | 節點切換、附件流量過大或帳號問題 | 固定節點，先測書目同步，再測附件 |
| Overleaf 編譯中斷 | 長連線不穩、DNS 異常或套件請求失敗 | 停用自動切換，分別測試編輯器與編譯 |
小撇步
修改配置前先匯出備份，並為每次變更留下日期與原因。研究期間若突然無法同步，可以快速還原上一版，而不是在壓力下同時修改代理、DNS 與瀏覽器設定。
最後，請把穩定性與安全性放在速度之前。學術工作通常不需要每個請求都走最快節點；一個地理位置穩定、延遲可接受、長連線可靠的節點，往往比頻繁跳轉的「自動選擇」更適合 Zotero 與 Overleaf。定期更新客戶端與規則集，移除不再使用的訂閱，並在公共電腦上完成研究工作後登出帳號，才能讓 Clash 真正成為研究流程的輔助工具，而不是新的不確定因素。