科研人员Clash配置指南：Scholar、Zotero与Overleaf工作流

科研工作流為何需要獨立的 Clash 分流策略

對研究人員而言，網路問題很少只表現為「某個網站打不開」。一天之內，你可能先用 Google Scholar 查找關鍵詞，再開啟 arXiv 閱讀預印本，透過 IEEE Xplore 或出版社平台下載論文，接著把 PDF、書目資料與標籤同步到 Zotero，最後在 Overleaf 編輯 LaTeX 專案、編譯並邀請合作者共同修改。這些服務的登入、搜尋、文件預覽、附件下載、API 同步與即時協作，可能使用不同的網域、CDN 和連線方式。只把瀏覽器設成「全域代理」，往往會帶來不必要的延遲；只代理一兩個熟悉的網域，又可能讓文獻同步或線上編譯在背景悄悄失敗。

Clash 的價值不只是提供一個代理開關，而是把不同流量按照用途分配到不同策略組。學術檢索、文獻管理與線上寫作通常需要穩定而非單純追求最低延遲的出口，因此建議先建立「研究工作流」的概念，再決定哪些網域應該直連、哪些應該交給代理、哪些需要保留手動切換。這樣做的好處是，當 Google Scholar 搜尋正常但 Zotero 同步失敗，或 Overleaf 網頁能開卻無法完成編譯時，你可以從規則命中和連線日誌開始定位，而不是反覆更換節點。

本文以支援 rules、proxy-groups、DNS 覆寫與 TUN 的 Clash／mihomo 核心為例。不同客戶端的按鈕名稱可能略有差異，但判斷原則一致：先備份設定檔，確認目前使用的核心版本，再逐步新增規則。若你是在學校、研究機構或公司網路中使用，還必須遵守組織的資訊安全政策；代理設定只能解決合法的連線路由問題，不能繞過帳戶權限、出版社授權或校方存取控制。

把 Scholar、Zotero 與 Overleaf 拆成四類流量

分流前最重要的工作，是把服務依照功能拆開，而不是單純依照品牌名稱猜測網域。Google Scholar 的搜尋頁、圖片或引用匯出可能依賴不同的 Google 服務；arXiv 的文章頁與 PDF 下載也可能由不同主機提供；Zotero 除了登入與同步，還有附件儲存、WebDAV 或第三方儲存空間；Overleaf 則同時涉及帳戶、專案介面、即時協作、原始碼上傳與雲端編譯。以下分類適合作為初始盤點，實際清單仍應以你的連線日誌為準。

對於網域規則，優先使用明確的 DOMAIN 和可信的 DOMAIN-SUFFIX，避免一開始就寫過大的關鍵字規則。例如，某個資料庫的登入頁可能跳轉到通用身份驗證服務，如果你只把入口網域加入代理，登入回跳仍可能因直連而失敗。反過來，若使用過寬的 DOMAIN-SUFFIX,google.com，又可能把與研究無關的影片、廣告或其他流量全部送入代理，造成不必要的頻寬消耗。規則的目標應是「覆蓋工作流所需的最小範圍」，而不是追求清單越長越好。

建議先為這幾個用途建立策略組，例如 RESEARCH、LITERATURE 與 OVERLEAF。若你只有少量節點，可以使用 select，在遇到同步或編譯問題時手動切換；如果希望核心定期測試節點，則可考慮 url-test。不過，延遲測試網址不一定代表 Scholar 搜尋、Zotero 附件或 Overleaf WebSocket 的真實體驗，因此不要只因探針顯示最低延遲，就認定該節點最適合整個研究流程。

DNS、Fake-IP 與學術網站規則的配置順序

許多「規則明明寫了卻沒有生效」的案例，根源並不在規則本身，而在 DNS 解析結果與核心模式不一致。Clash 需要先知道應連線的主機名稱，才能把流量交給對應的策略；如果本地 DNS、系統快取、瀏覽器安全 DNS 與 Clash DNS 同時介入，就可能出現瀏覽器解析到一個地址、核心日誌卻顯示另一個地址的情況。研究網站常含有多個重導向、靜態資源和下載主機，這種差異會在 PDF、引用匯出或同步附件時被放大。

若你使用 Fake-IP，應先確認核心版本、TUN 模式與客戶端對 Fake-IP 的支援方式，再決定是否加入特定網域的 fake-ip-filter。本機回環位址、區域網路主機、校園內部域名與某些需要真實解析結果的服務，通常不適合直接套用 Fake-IP。Zotero 若透過校內 WebDAV 或內網儲存同步，也應將該主機放入合適的排除清單，否則代理可能把內部附件流量送到外部節點，既增加延遲，也可能違反機構的資料管理要求。

DNS 的配置順序建議如下：先確認系統時間與網路介面正常，再確認 Clash DNS 是否正在監聽；接著只啟用一種主要解析路徑，避免多個安全 DNS 或瀏覽器 DNS 與核心互相競爭；最後再測試規則命中。每次只改一項，並記錄修改前後的結果。你可以分別打開 Scholar 搜尋頁、arXiv PDF、IEEE Xplore 登入頁、Zotero 同步和 Overleaf 專案，觀察連線日誌中的主機名稱、解析地址、策略組及錯誤類型。

重要提醒：不要因為「能打開首頁」就判定服務完全正常。首頁通常只代表少量 HTTPS 請求成功；真正暴露分流問題的，往往是 PDF 下載、引用匯出、Zotero 附件同步、Overleaf WebSocket 或雲端編譯這些第二階段請求。

Zotero 文獻同步與 Overleaf 編譯的實務配置

Zotero 的使用體驗可以拆成三個層次：帳戶登入與同步資料、附件檔案傳輸，以及本機資料庫與瀏覽器的互動。書目資料同步成功，不代表附件也一定同步完成；附件同步停滯時，應先查看 Zotero 的同步訊息，確認是帳戶授權、儲存空間、WebDAV 服務，還是某個大型 PDF 傳輸失敗。若你的附件使用 WebDAV，規則不應只圍繞 zotero.org，而要把實際使用的 WebDAV 主機獨立確認，並讓它與帳戶服務使用一致且穩定的策略。

Zotero 附件常包含大量 PDF，小型書目請求可能幾秒完成，大型檔案卻在中途因節點切換、連線重置或代理超時而失敗。因此，文獻同步策略不宜頻繁使用自動切換。若 url-test 每次健康檢查後更換節點，正在上傳的附件可能遭遇新的出口，導致重試或產生重複佇列。對同步工作來說，穩定的固定節點通常比瞬時低延遲更重要；完成同步後，再切回一般瀏覽策略即可。

Overleaf 的主要問題則常出現在「介面可用，但協作或編譯不穩」。即時編輯可能依賴長時間連線，專案上傳涉及多個請求，編譯則可能在提交原始碼後等待雲端工作佇列。若不同階段被分到不同出口，服務端可能把它視為會話異常，或在重導向後遺失認證狀態。建議把 Overleaf 的主站、登入相關主機與實際日誌中出現的編譯或靜態資源主機，暫時收斂到同一個 OVERLEAF 策略組，再逐步縮小規則範圍。

如果 Overleaf 顯示編譯失敗，不要立即把它判定為 Clash 導致。先在 Overleaf 日誌確認是 LaTeX 錯誤、資源超限、專案檔案缺失，還是連線在提交前後中斷。若只是編譯器報告 undefined control sequence 或缺少套件，代理規則無法修復 LaTeX 原始碼；若瀏覽器一直顯示等待、專案上傳停在某個百分比，才值得回頭檢查連線日誌、DNS、WebSocket 與策略組切換紀錄。

用最小測試流程確認整條研究鏈

1. 先在不修改規則的狀態下記錄 Scholar 搜尋、arXiv PDF、資料庫登入、Zotero 同步與 Overleaf 編譯的結果。
2. 只新增學術檢索相關規則，確認搜尋與 PDF 下載是否都命中預期策略。
3. 再加入 Zotero 帳戶與附件儲存主機，等待一筆小型文獻同步完成後，才測試較大的 PDF。
4. 最後處理 Overleaf，先測試登入與專案開啟，再測試協作、檔案上傳與雲端編譯。
5. 每一步都保留連線日誌與錯誤時間，避免把不同階段的問題混在同一輪修改中。

常見故障排查與長期維護方法

Scholar 搜尋結果空白或反覆出現驗證頁時，先檢查瀏覽器是否保留了過期 Cookie、系統時間是否正確，以及 Google 相關主機是否在同一個策略意圖下運作。若只有圖片或引用按鈕失效，表示頁面主體已通但子資源可能命中不同規則。此時不要立刻擴大到整個 Google 網域，應從開發者工具或 Clash 連線日誌找出實際失敗的主機，再增加最小化規則。

arXiv 或 IEEE Xplore 能開啟但 PDF 下載逾時，常見原因包括下載主機與入口主機不同、節點對大檔案傳輸不穩定、或瀏覽器在重導向後改走直連。可以先用較小的 PDF 測試，再比較瀏覽器下載與命令列請求的結果；如果只有瀏覽器失敗，檢查擴充功能與瀏覽器代理設定；如果所有客戶端都失敗，則回到策略組、DNS 和出口品質排查。出版社平台還可能依賴校園 IP、機構登入或 DOI 重導向，代理切換過於頻繁反而會讓授權狀態失效。

Zotero 同步錯誤應先區分「書目同步失敗」與「附件同步失敗」。前者多與帳戶授權、API 請求或時間設定有關；後者則要檢查儲存空間、WebDAV 認證、檔案大小與長連線穩定性。若你剛更新訂閱或切換節點後才出現問題，先把同步策略固定在一條穩定線路，等待佇列收斂，再考慮更換節點。不要在同步進行中連續修改 DNS、TUN 和代理組，否則很難判斷是哪個變更造成重試。

Overleaf 若出現登入迴圈，可先關閉重複的瀏覽器代理擴充功能，確認系統代理與 Clash TUN 沒有同時接管同一流量，再清理該站點的登入資料並重新測試。若編輯器載入但游標同步延遲，觀察是否存在 WebSocket 失敗、連線被重置或出口頻繁變更。若只有某個專案編譯失敗，先在 Overleaf 的編譯日誌確認是否屬於模板或套件錯誤；若所有專案都無法提交，才優先檢查 Clash 規則和網路層。

長期維護時，建議把規則分成「手動核心規則」與「訂閱規則集」兩層，並在每次更新前備份目前可用配置。不要直接修改訂閱產生的巨大 YAML，因為下一次更新可能覆蓋本地變更；更穩妥的做法是保留自己的覆寫檔、策略組命名與測試紀錄。每隔一段時間重新檢查實際日誌，刪除已經不再使用的網域，並確認研究機構、出版社或雲端服務近期是否更換了 CDN。規則越精準，日後發生故障時越容易知道是哪一層出了問題。

與只提供全域開關的傳統 VPN 相比，Clash 類工具能依網域、規則集與策略組精細區分 Scholar 搜尋、Zotero 同步和 Overleaf 編譯；而部分瀏覽器代理擴充功能又無法穩定處理桌面應用程式、WebDAV 附件或長時間編譯連線。若你希望把本文的研究工作流分流落實成可備份、可觀察、可逐步調整的配置，Clash V.CORE 會比單純切換系統代理更容易管理，也能在同一介面檢查連線與規則命中情況；完成配置後，可前往下載頁取得適合你平台的版本，從小範圍測試開始建立可靠的科研網路環境。