對研究人員而言，網路工具往往不是單獨運作的：Zotero 負責文獻收集、附件管理與資料同步，學術資料庫提供檢索與全文下載，Overleaf 則承擔論文撰寫、多人協作和線上編譯。任何一個環節出現連線逾時，都可能造成附件下載失敗、引用資料不同步、Git 儲存庫無法更新，甚至讓編譯工作停在一半。Clash 的價值不在於讓所有流量一律經過代理，而是按照服務用途、域名與網路環境進行精細分流。本篇以研究人員常見的工作流程為主軸，說明如何使用 Clash 或 Mihomo，建立 Zotero、Overleaf 與學術資料庫之間較穩定、容易維護的代理方案。

先拆解研究工作的網路流程

在開始寫規則之前，應先把研究工作拆成幾類流量。Zotero 桌面版本身可能同時連線到官方服務、WebDAV 儲存空間、學校或研究機構的資料庫，以及第三方 PDF 來源；瀏覽器則會存取 Overleaf、出版社網站、預印本平台、ORCID 和 GitHub 等服務。這些流量不一定需要相同的出口，因此「全域代理」通常不是最理想的長期方案。

工作環節常見服務主要問題建議路由
文獻檢索Google Scholar、Crossref、PubMed、出版社平台頁面載入慢、驗證或全文連結失敗依實際可達性使用代理
Zotero 同步Zotero Sync、WebDAV、雲端附件服務同步逾時、附件佇列卡住為同步服務設定獨立策略
論文協作Overleaf、GitHub、GitLab專案頁面空白、編譯請求失敗瀏覽器與 Git 流量走穩定節點
校內資源圖書館、校園 VPN、內部資料庫代理後無法登入或被判定來源異常校內網域優先直連
一般日常流量本地網站、銀行、校務系統延遲增加、驗證碼變多遵循 GEOIP 或直連規則

這種拆分方式有兩個好處。第一，能降低代理節點負載，讓真正需要跨區或較穩定出口的服務得到足夠頻寬。第二，遇到問題時更容易定位：如果 Zotero 能登入但 WebDAV 附件同步失敗，問題可能出在附件服務的域名或策略；如果 Overleaf 首頁可開啟但編譯結果無法返回，則應查看連線詳情，而不是直接更換整份配置。

先確認使用權限：學校圖書館、出版社和資料庫通常有明確的授權條款。Clash 只能改善合法網路連線與分流，不應用於繞過訂閱限制、校方存取政策或大量抓取受版權保護的內容。

Zotero 代理方案如何設計

Zotero 的網路流量不只是一個固定域名。使用者可能透過 Zotero 官方同步服務同步書目資料，也可能使用 WebDAV 儲存 PDF 附件；此外，從瀏覽器將資料匯入 Zotero 時，還會涉及出版社頁面、DOI 解析服務和瀏覽器連線。因此，最穩妥的做法是先在 Clash 的連線頁面觀察實際域名，再逐步補充規則。

若你使用 Zotero 官方同步，建議把官方帳號與同步相關域名放入同一個策略組，並使用一個延遲穩定、允許長連線的節點。若使用 WebDAV，則應以 WebDAV 服務商提供的主域名為準，不要只憑服務品牌名稱猜測域名。許多雲端儲存服務會將登入、API、檔案下載分配到不同的子域名，過度精簡的規則可能造成「能登入、不能下載」的情況。

Zotero 與學術服務分流示例
proxy-groups:
  - name: Research-Proxy
    type: select
    proxies:
      - Auto
      - Stable-Node
      - DIRECT

rules:
  # Replace domains with services you are authorized to use
  - DOMAIN-SUFFIX,zotero.org,Research-Proxy
  - DOMAIN-SUFFIX,webdav.example.edu,Research-Proxy
  - DOMAIN-SUFFIX,crossref.org,Research-Proxy
  - DOMAIN-SUFFIX,doi.org,Research-Proxy
  - DOMAIN-SUFFIX,overleaf.com,Research-Proxy
  - DOMAIN-SUFFIX,github.com,Research-Proxy
  - DOMAIN-SUFFIX,edu.cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Research-Proxy

上面的域名只是結構示例，不能直接視為所有環境的完整清單。特別是 WebDAV 服務，應把你實際使用的伺服器名稱替換進去。若校方要求先連線校園 VPN 才能使用資料庫，校內域名通常應直連，或交由校方 VPN 客戶端處理；不要在 VPN 和 Clash 之間反覆切換，否則可能出現路由優先級衝突。

Overleaf 與線上編譯的分流重點

Overleaf 的使用體驗包含三個不同階段：登入與專案頁面載入、編輯器與協作狀態同步、提交編譯並取得 PDF 結果。這些請求可能使用 HTTPS 長連線、WebSocket 或其他背景請求。若規則只放行首頁域名，而沒有涵蓋必要的子域名，就可能出現編輯器載入不完整、同事游標不更新或編譯結果長時間停留在等待狀態。

建議將 overleaf.com 及其必要子域名交給同一個穩定策略組，避免同一個專案的前端、API 和編譯請求在不同出口之間跳轉。節點切換也不宜過於頻繁，尤其是正在編譯大型文件、上傳圖片或同步大量專案檔案時。若使用 url-test，可以設定合理的 tolerance，避免因幾十毫秒的差異反覆切換。

Overleaf 的編譯錯誤不一定都是代理造成的。TeX 套件缺失、圖片格式不支援、主檔案設定錯誤或專案資源過大，都可能產生類似的等待感。因此排查時應先在瀏覽器開發者工具或 Clash Dashboard 中確認請求是否成功，再查看 Overleaf 的編譯日誌，避免把語法錯誤誤判為網路錯誤。

動手建立研究工作流配置

以下步驟適用於 Clash Verge、Clash Verge Rev 和基於 Mihomo 的客戶端。不同客戶端的按鈕名稱可能略有差異，但核心流程都是匯入配置、確認代理組、添加規則並觀察連線。

  1. 備份目前配置：先複製現有 YAML 檔案，或在客戶端建立一個獨立的研究工作配置。不要直接修改唯一的日常配置，以免規則寫錯後難以回復。
  2. 確認節點可用性：在代理頁面測試至少兩個節點。優先選擇延遲穩定、丟包較少的節點，而不是只看一次測速結果最低的節點。
  3. 建立策略組：將研究相關流量放入 Research-Proxy，並保留一個 DIRECT 選項。這樣遇到服務本身不需要代理時，可以快速切回直連測試。
  4. 加入最小規則：先只加入 Zotero、WebDAV、Overleaf 和你確定需要的學術服務域名。每增加一條規則，就立即測試一次，不要一次貼入來源不明的大型規則集。
  5. 重載配置：儲存 YAML 後，在客戶端執行配置檢查或重新載入。若提示格式錯誤，優先檢查縮排、冒號、列表符號和策略組名稱是否完全一致。
  6. 逐項驗證：先登入 Zotero 並執行同步，再下載一個小型附件；接著開啟 Overleaf 專案、修改一行文字並編譯。最後檢查 GitHub 或其他協作服務是否正常。
  7. 記錄實際域名：在 Dashboard 的 Connections 頁面查看請求目標與命中規則。若某個請求落入 MATCH，先記下域名，再決定是加入代理、直連或拒絕。
建議採用最小可用配置：先讓一個 Zotero 同步任務和一個 Overleaf 專案穩定完成，再擴展到更多資料庫。每次只修改一個變數，排錯速度會比直接更換整份配置快很多。

DNS、TUN 與桌面應用的注意事項

瀏覽器通常遵循系統或代理設定，但 Zotero 等桌面應用不一定完全相同。有些應用會自行進行 DNS 解析，或使用系統代理以外的連線方式。當你發現瀏覽器可以開啟 Overleaf，而 Zotero 仍然同步失敗時，應檢查客戶端是否啟用了系統代理，以及 Zotero 是否支援並使用該代理。

在 Windows、macOS 或 Linux 上，如果希望讓沒有代理設定入口的桌面應用也遵循 Clash 規則，可以考慮 Mihomo 的 TUN 模式。TUN 會在系統網路層攔截流量，再交給 Clash 進行域名和 IP 規則匹配。啟用前應確認客戶端具備管理員或系統擴展權限，並留意它可能與其他 VPN、虛擬網卡、校園網認證程式互相干擾。

DNS 模式方面，Mihomo 常見的 fake-ip 適合以域名規則為核心的分流場景，但部分校內系統、區域網路服務和依賴真實 IP 的應用可能需要加入 fake-ip-filter。研究工作中常見的內部 Git、校園印表機、NAS 或圖書館區域網路入口，都不應在未測試的情況下直接套用相同的 fake IP 規則。

研究環境的 DNS 基本示例
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost'
    - '*.edu.internal'
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

如果啟用 TUN 後校內資源無法使用，可以先暫時關閉 TUN，保留系統代理，分別測試瀏覽器和 Zotero。若問題只在 TUN 模式出現，通常與路由優先級、校園 VPN 或內部域名解析有關。不要為了讓單一服務恢復而長期設定 skip-cert-verify: true，這會降低 TLS 憑證驗證的安全性。

常見故障與排查順序

研究工作流最忌諱「看到失敗就換節點」。更有效的方法是按照應用、域名、DNS、路由和服務本身的順序逐層排查。

症狀優先檢查項目處理方法
Zotero 能登入但同步卡住同步域名、WebDAV 域名、附件大小查看 Connections，為實際附件服務補充規則
PDF 能開啟但下載失敗重新導向域名、CDN、瀏覽器下載請求追蹤最終域名，不要只放行出版社首頁
Overleaf 頁面空白瀏覽器快取、WebSocket、代理組連通性先清除快取，再固定穩定節點測試
Overleaf 編譯一直等待編譯服務狀態、長連線、專案本身錯誤查看編譯日誌，並用直連與代理分別比較
校內資料庫無法登入校園 VPN、校內 DNS、來源 IP 要求將校內域名直連，依學校要求使用 VPN
所有網頁都變慢全域模式、DNS 延遲、節點負載切換規則模式，降低不必要的代理流量

使用 Clash Dashboard 時，重點查看三個欄位：目標域名、命中的規則和實際使用的策略組。若目標顯示為 IP 而不是域名，可能需要檢查 DNS 模式或是否使用了 IP-CIDR 規則；若命中的是 MATCH，代表前面的規則沒有覆蓋該請求；若策略組顯示正確但請求仍然逾時，則應測試其他節點或檢查服務本身是否暫時不可用。

另外，Zotero 的同步問題要區分「書目資料」和「附件」。書目資料量通常較小，附件同步則可能受到檔案大小、WebDAV 配額、伺服器限制和連線中斷影響。Overleaf 也要區分「專案檔案同步」和「伺服器編譯」兩個階段。只要拆開測試，就能避免用錯誤方向修改規則。

讓配置適合長期研究工作

研究專案往往持續數月甚至數年，因此配置的可維護性比短時間內追求最高速度更重要。建議將規則按用途分組，例如 Research-Proxy、Campus-Direct 和 Collaboration，並在 YAML 中保留簡短註記。規則順序也要保持清楚：特殊域名放在前面，較廣泛的域名後綴放在後面，最後才使用 GEOIP 或 MATCH 作為兜底。

節點方面，至少準備一個主節點和一個備用節點。對 Zotero 同步和 Overleaf 編譯而言，穩定性通常比峰值頻寬重要；若節點頻繁切換，長連線可能被中斷，正在上傳的附件或編譯請求也可能失敗。可以使用 fallback 做主備切換，但測速 URL 應選擇穩定、回應簡單的地址，不要使用需要登入或內容變化很大的頁面。

  • 每次修改規則後，測試 Zotero 同步、附件下載和 Overleaf 編譯三個核心操作。
  • 定期檢查規則 Provider 的更新時間，避免使用長期不維護的域名清單。
  • 為校內資源保留直連方案，並記錄校園 VPN 的啟用順序。
  • 不要在配置中公開訂閱連結、代理密碼或 Dashboard 的 secret。
  • 發現服務恢復後，將臨時加入的廣泛規則收窄，避免日後誤代理其他流量。

一套好的研究網路配置，應該讓你幾乎感覺不到它的存在：本地和校內服務保持快速直連，需要穩定出口的學術平台使用固定策略組，Zotero 能可靠同步，Overleaf 能順利協作與編譯。完成初始設定後，建議在不同網路環境各測試一次，例如家用寬頻、校園網和行動熱點，確認規則不是只適用於單一場所。若你還沒有合適的 Clash 客戶端，可以先選擇與作業系統相符的版本，再按照上述流程逐步建立自己的研究工作流。

立即開始

用 Clash 掌控您的流量

支援 Windows、macOS、Linux、Android 與 iOS，靈活規則，開箱即用。

免費下載 查看設定指南 →