研究人員的網路工作，為什麼需要獨立分流？

對研究人員而言，Clash 並不是單純用來「開啟代理」的工具，而是把文獻檢索、資料同步、寫作協作與日常網路流量分開管理的本機網路控制台。一天之內，你可能先在 Google Scholar、PubMed 或出版社平台搜尋論文，接著用 Zotero Connector 儲存書目與附件，再透過 Zotero WebDAV 或官方同步服務同步資料，最後開啟 Overleaf 與同學共同編輯 LaTeX 專案。這些服務的網域、連線模式和對延遲的敏感度並不相同，如果全部採用同一種直連或同一個代理策略，往往會出現「搜尋頁面能開、PDF 下載失敗」、「Zotero 同步一直轉圈」或「Overleaf 編輯器偶爾斷線」等問題。

搜尋「Clash 學術網站分流」「Zotero 代理設定」或「Overleaf 連線不穩」時，真正需要解決的通常不是某一個神奇節點，而是如何讓不同學術服務穩定地命中正確規則。本文以合法授權的研究用途為前提，示範如何建立學術平台、Zotero 與 Overleaf 的分流思路，同時保留學校內網、校園 VPN、圖書館服務及本地網站的直連路徑。

先拆解服務：學術網站、Zotero 與 Overleaf 並非同一條鏈路

設計規則前，建議先把研究工作拆成幾個流量桶。這樣做比直接寫一條過寬的 DOMAIN-KEYWORD,google 更安全，也更容易在 Clash 的連線紀錄裡確認命中結果。下面的網域是實務上的起點，實際使用時仍應以瀏覽器、Zotero 及 Overleaf 的連線日誌補充，因為服務可能因地區、登入狀態或 CDN 調整而使用不同主機。

• 文獻檢索與學術搜尋：可觀察 scholar.google.com、pubmed.ncbi.nlm.nih.gov、semanticscholar.org、arxiv.org 等主機。搜尋頁面本身通常不是唯一端點，結果中的出版社、DOI 解析與 PDF 下載可能會跳轉到另一組網域。
• 出版社與資料庫：Elsevier、Springer、Wiley、IEEE、ACM、JSTOR 或學校圖書館代理入口各有不同網域。不要因為某篇論文來自某出版社，就把整個頂級網域全部交給代理；應優先加入你實際需要、且確認屬於授權範圍的主機。
• Zotero 同步：Zotero 帳號登入、書目同步、附件同步與 WebDAV 儲存可能分屬不同服務。Zotero 客戶端也可能使用系統 DNS 與獨立的 HTTPS 連線，因此「瀏覽器能登入」不代表 Zotero 一定能同步。
• Overleaf 協作：Overleaf 網頁編輯器通常需要穩定的 HTTPS 長連線，部分即時更新、登入與資源載入可能來自不同主機。若只測試首頁，而沒有觀察編輯器載入後的連線，容易誤判設定已經完成。
• 校園與本地服務：校園入口、內部 Git、圖書館認證、校內 DNS、印表機與區域網路裝置通常應維持 DIRECT。若使用 TUN 模式，還要特別處理私有網段與校園網關，避免本機研究資源反而被送往遠端代理。

分流的核心原則是最小化匹配範圍、保留可觀察性。如果只為了開啟某個出版社頁面，就把整個 DOMAIN-SUFFIX,edu 交給代理，可能會誤傷學校內部服務；如果把所有 Google 相關網域都代理，則可能造成 Google Drive、學校登入或本地服務的路徑混亂。規則越精準，後續排錯越容易。

Zotero 分流：先分辨登入、書目同步與附件同步

Zotero 的「同步失敗」是一個過於籠統的說法。你需要先觀察是帳號登入失敗、書目資料無法更新，還是附件檔案卡在上傳或下載。書目資料通常體積小，附件則可能是數十 MB 的 PDF 或大量掃描檔；兩者對連線穩定性、逾時與儲存配額的要求不同。若使用 Zotero 官方儲存服務，請以 Zotero 官方文件與實際連線紀錄確認端點；若使用 WebDAV，則應將你所使用的 WebDAV 主機單獨列入規則，而不是猜測一個通用網域。

推薦先建立一個名為 RESEARCH 或 ACADEMIC 的策略群組，再將 Zotero、檢索平台與 Overleaf 分開建立規則名稱。這樣在連線列表中看到某個請求時，可以立即知道它屬於哪個用途。對附件同步而言，固定一個延遲穩定、允許長時間 HTTPS 傳輸的節點，通常比使用頻繁自動切換的測速組更可靠。Zotero 正在同步大檔時，若策略組中途切換節點，可能導致上傳重試、檔案校驗失敗或同步佇列重新開始。

YAMLproxy-groups:
  - name: RESEARCH
    type: select
    proxies:
      - Research-Primary
      - Research-Backup
      - DIRECT

rules:
  - DOMAIN-SUFFIX,scholar.google.com,RESEARCH
  - DOMAIN-SUFFIX,arxiv.org,RESEARCH
  - DOMAIN-SUFFIX,overleaf.com,RESEARCH
  - MATCH,DIRECT

上面的設定只是結構示例，不代表所有學術服務都使用這些網域，也不表示應該無條件代理。加入規則後，請在 Zotero 開啟同步，觀察 Clash 連線紀錄是否出現實際主機；若日誌只看到一個登入網域，卻沒有看到附件儲存端點，便不能據此判定附件同步已經成功。若你使用 WebDAV，請把 WebDAV 主機放在明確的 DOMAIN 或 DOMAIN-SUFFIX 規則中，並確認 URL、帳號與應用程式專用密碼沒有輸入錯誤。

動手設定：在 Clash 中建立研究工作流

以下步驟適用於使用 Clash Verge Rev、Mihomo Party 或其他支援 Mihomo 核心的桌面客戶端。介面名稱可能略有不同，但順序可以保持一致：先確認核心，再建立策略，最後用實際應用程式驗證。不要一開始就啟用大量規則集，否則遇到問題時很難知道究竟是 DNS、規則優先順序還是節點本身造成的。

1. 準備合法的設定檔與研究策略組：匯入你有權使用的訂閱或 YAML 設定檔，確認核心顯示為 Mihomo 或相容版本，然後建立 RESEARCH 策略組。先放入一個固定測試節點、一個備用節點與 DIRECT，不要立即使用十幾個自動切換選項。
2. 整理主機清單：從瀏覽器開啟學術搜尋、出版社頁面與 Overleaf 編輯器，再從 Clash 連線紀錄複製實際主機名。Zotero 則在同步前後查看日誌或系統連線，將登入、書目與附件使用的主機分開記錄。
3. 把規則放在寬泛規則之前：將明確的 DOMAIN、DOMAIN-SUFFIX 規則置於 GEOIP、GEOSITE 或 MATCH 之前。規則採先匹配原則時，順序錯誤會使你精心建立的學術分流根本沒有機會生效。
4. 先用瀏覽器驗證：依序測試搜尋頁、論文落地頁、PDF 下載與 Overleaf 專案。每完成一項，就在連線列表確認主機、命中規則與策略組一致，並記錄是否發生重新導向或 TLS 錯誤。
5. 再測試 Zotero：先執行書目同步，再測試一個小型附件。若書目成功、附件失敗，優先檢查附件主機、WebDAV 位址、檔案大小限制及節點長連穩定度，不要直接重裝 Zotero。
6. 最後處理 TUN 與終端機：如果你需要用命令列下載資料集、執行 Git 或讓不遵守系統代理的應用程式進入同一條路徑，再啟用 TUN。啟用後重新檢查校園網段、印表機、內部 Git 與本地 DNS，避免全域接管造成反效果。

如果你的學校要求透過校園 VPN 或圖書館代理登入資料庫，請把該流程視為另一條合法認證鏈路，不要用 Clash 規則取代學校授權。實務上可以讓校園認證入口維持直連，待 VPN 建立後再觀察資料庫流量是否需要由系統路由處理。若學校提供固定的 Proxy PAC 或指定 DNS，優先依 IT 文件設定，並避免同時疊加多個互相不知情的代理層。

Overleaf 與學術網站的穩定性排查

Overleaf 的問題通常分為「頁面打不開」「編輯器能載入但無法即時更新」以及「編譯請求長時間等待」三類。前兩者比較容易與 HTTPS、WebSocket 或長連線穩定度相關；後者則可能是專案資源、編譯佇列、LaTeX 錯誤或平台服務狀態。Clash 能協助你驗證出站路徑，但不能把所有平台端錯誤都歸因於代理。

• 首頁可以開、編輯器卡住：查看連線列表是否在載入專案後出現新的主機。若新主機命中 DIRECT，請只為實際觀察到的端點增加規則，不要直接代理整個網域樹。
• 編輯器偶爾失去連線：暫時將 Overleaf 策略組固定到單一節點，避免 url-test 在長連線期間切換出口。若固定節點後恢復，問題多半與節點抖動、TCP 長連或出口品質有關。
• PDF 預覽不更新：先確認是否真的完成編譯，再檢查瀏覽器開發者工具或 Clash 連線紀錄中的資源請求。瀏覽器快取、專案錯誤與代理規則都可能造成相似現象。
• 出版社頁面可以開、PDF 下載逾時：落地頁與 PDF 可能使用不同 CDN 或重新導向主機。請從失敗請求的實際網域補規則，並檢查節點是否支援穩定的大檔傳輸。

DNS 模式也值得單獨檢查。若瀏覽器解析到一個可用 IP，但 Zotero 或其他原生客戶端使用不同 DNS，兩者可能看似走同一規則，實際卻連到不同服務端點。啟用 fake-ip 或 redir-host 前，先閱讀目前客戶端對 DNS 劫持、局域網域名與校園內部解析的處理方式。對研究環境而言，能正確解析內網主機往往比單純追求某個測試網站的最低延遲更重要。

長期維護：讓規則跟著研究流程，而不是越堆越亂

學術工作流會變動：你可能從 Google Scholar 轉向 PubMed，從 Zotero 官方儲存改用 WebDAV，也可能加入新的 Overleaf 團隊或學校 VPN。建議每隔一段時間整理一次規則，刪除已不再使用的網域，將規則依「檢索」「同步」「協作」「校園直連」分組，並為每個策略組保留一個明確的直連或停用測試選項。這能讓你在服務異常時快速做 A/B 測試，而不必一次修改整份設定檔。

不要把完整訂閱連結、研究帳號、Zotero WebDAV 密碼或學校 VPN 憑證放進公開 YAML、截圖或 Issue。分享除錯資訊時，至少遮蔽使用者名稱、Token、Cookie、內網 IP 與完整 URL 參數。若團隊共同維護規則，應使用版本控制保存不含敏感資訊的規則片段，並在每次更新時記下「新增哪個主機、解決什麼現象、是否確認直連仍正常」。這比盲目收集網域清單更有價值。

最後，與一些只提供簡單全域開關的同類工具相比，研究工作流最常遇到的限制是規則可觀察性不足、原生應用程式兼容性不一，以及缺少針對 Zotero 附件同步與 Overleaf 長連線的實作說明。Clash 官網 的優勢在於把策略組、連線日誌、TUN 與終端代理放在同一套可逐步驗證的流程中，方便你保留校園與本地直連，同時為學術平台建立較精準的分流；如果你正準備整理自己的研究網路環境，不妨前往下載 Clash 官網，再依本文的主機觀察與分階段測試方法開始設定。