2026-08-01 核心解析 約 9 分鐘讀完

研究人員 Clash 實戰設定：Scholar、Zotero 與學術資料庫順暢使用

研究工作往往要在 Scholar、arXiv、Zotero 和 Overleaf 之間頻繁切換。本指南以研究人員的實際流程為核心，整理學術網站分流、文獻下載與資料同步的 Clash 設定方法。

先理解研究工作流與代理邊界

研究人員使用代理工具時,通常不是單純把所有流量切到同一個節點。一天之內可能先用 Google Scholar 搜尋論文,再開啟 arXiv 閱讀預印本,透過出版社網站下載 PDF,接著讓 Zotero 同步文獻與附件,最後在 Overleaf 編譯論文。這些服務的網域、登入狀態、下載方式和對網路的要求並不相同,適合用「規則分流」處理,而不是長時間使用全域模式。

本文以 mihomo 核心的 Clash Verge Rev、Clash Nyanpasu、FlClash 或其他相容用戶端為例。介面名稱可能是「代理」「設定檔」「覆寫」或「擴充設定」,但需要調整的核心概念一致:讓學術網站與必要的下載請求走代理,本地服務、校園資源和不需要代理的連線保持直連。

  • 瀏覽與搜尋:Google Scholar、部分學術搜尋站點及其靜態資源可交給代理,避免頁面載入不完整或驗證失敗。
  • 文獻下載:出版社、預印本平台和資料庫的 PDF 請求通常跟隨網域規則,不要只代理首頁而漏掉下載網域。
  • 文獻管理:Zotero 的同步、WebDAV、附件下載和瀏覽器 Connector 可能使用不同連線,需要分別觀察。
  • 寫作協作:Overleaf 的編輯器、編譯服務與登入頁通常使用多個網域,規則過度嚴格時會出現能開首頁但無法編譯的情況。

先確認使用權限與服務條款

代理只能改變連線路徑,不能取代學校或研究機構的訂閱權限。存取出版社全文、校園資料庫與 VPN 資源時,仍應使用合法帳號、機構認證或圖書館提供的遠端存取方式,不要用代理繞過付費限制。

用規則模式安排學術網站分流

在 Clash 代理頁選擇「規則」模式後,核心會依序比對設定檔中的 rules。一般做法是把明確的學術網域放在較前面,再交給常規規則處理。規則順序很重要:如果前面已經有一條寬泛的 GEOIP、MATCH 或直連規則,後面的學術網域規則就不會被執行。

以下是一個示意片段,可放在 mihomo 設定檔的 rules 區段。實際使用時應依自己的訂閱格式、研究機構網域和節點群組名稱調整:

rules:
  - DOMAIN-SUFFIX,scholar.google.com,RESEARCH
  - DOMAIN-SUFFIX,arxiv.org,RESEARCH
  - DOMAIN-SUFFIX,export.arxiv.org,RESEARCH
  - DOMAIN-SUFFIX,overleaf.com,RESEARCH
  - DOMAIN-SUFFIX,zotero.org,RESEARCH
  - DOMAIN-SUFFIX,semanticscholar.org,RESEARCH
  - DOMAIN-SUFFIX,crossref.org,RESEARCH
  - DOMAIN-SUFFIX,doi.org,RESEARCH
  - DOMAIN-SUFFIX,edu.cn,DIRECT
  - DOMAIN-SUFFIX,ac.uk,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

RESEARCH 是代理策略群組的名稱,並不是 mihomo 固定保留字。如果設定檔裡的群組叫「Proxy」「節點選擇」或「自動選擇」,必須換成完全相同的名稱。規則也不代表所有論文下載都一定只涉及列出的主網域,有些出版社會把附件放在 CDN 或獨立的檔案網域,遇到 PDF 下載卡住時應從 Connections 和 Logs 找出實際目標網域,再補充規則。

規則類型適合用途注意事項
DOMAIN只匹配一個完整網域不會自動涵蓋其子網域
DOMAIN-SUFFIX涵蓋主網域與子網域學術平台最常用,但範圍較寬
DOMAIN-KEYWORD按網域文字關鍵字匹配容易誤傷不相關網站,不宜大量使用
RULE-SET引用可更新的網域規則集規則集本身也需要能正常下載
MATCH處理所有尚未命中的流量通常放在 rules 最後

Scholar、arXiv 與資料庫的實際設定

Google Scholar 的頁面不一定只載入 scholar.google.com。搜尋結果中的 DOI 連結會跳到出版社,「所有版本」可能前往機構典藏或預印本平台,引用匯出功能也可能請求額外的 Google 網域。因此,測試時不要只檢查首頁,應完成一次搜尋、開啟結果、查看 PDF 或匯出 BibTeX,再觀察每一步的連線。

arXiv 的文章頁、摘要頁與 PDF 通常位於同一主網域,但不同網路環境可能對 export.arxiv.org 的 API 請求有不同表現。若使用 Zotero 或其他工具批次抓取 arXiv 書目資料,可以把相關網域放進同一個策略群組,並避免在短時間內大量重試。服務端的速率限制不是換節點就能無限突破,研究用途應保持合理請求頻率。

出版社與學術資料庫的網域組成更複雜。ScienceDirect、SpringerLink、Wiley、ACM、IEEE 等平台可能分別使用登入網域、內容網域、圖片網域、下載 CDN 和驗證服務。最穩妥的排查方法是打開 Clash 的 Connections:

  1. 先在瀏覽器開啟資料庫首頁,搜尋一篇有權限閱讀的文章。
  2. 點擊 HTML 全文或 PDF,等待頁面完成,記錄被命中的網域及最終策略。
  3. 如果主頁走了代理但 PDF 命中 DIRECT,檢查 PDF 網域是否應加入相同的 DOMAIN-SUFFIX 規則。
  4. 如果登入頁反覆跳轉,不要立刻把整個網站所有網域都設為代理;先查看是否有 Cookie、驗證或時間同步問題。
  5. 完成測試後重新載入瀏覽器,確認規則修改沒有只對舊連線生效。

校園網路與代理不要互相套娃

部分大學圖書館要求先連校園 VPN,再以機構 IP 存取資料庫。此時若把校園 VPN、Clash TUN 和瀏覽器獨立代理同時疊加,可能造成路由循環或認證失效。先確認機構要求的連線順序,通常只保留一個主要代理入口即可。

Zotero 同步與附件下載

Zotero 的同步包含書目資料、筆記、標籤和收藏結構;附件檔案則可能受 Zotero 儲存方案或 WebDAV 設定影響。這兩類資料不是完全相同的請求,因此「瀏覽器可以開學術網站」不代表 Zotero 一定能同步,反過來也一樣。

在 Zotero 裡先確認同步帳號、同步開關和附件同步方式。若使用 Zotero Storage,請檢查帳號空間與同步狀態;若使用 WebDAV,則需要確認 WebDAV 伺服器位址、帳號密碼和服務商要求的 HTTPS 設定。不要把 WebDAV 伺服器盲目加入學術網站規則,它可能是一般雲端服務,應按實際連線結果決定 DIRECT 或 RESEARCH。

  • 瀏覽器 Connector 找不到書目:先確定瀏覽器與 Zotero 桌面程式都在執行,再看網站頁面是否完整載入。Connector 讀取的是網頁中的結構化書目資料,不是單純下載 PDF。
  • 書目能同步但附件失敗:查看 Zotero 同步錯誤訊息,區分儲存空間不足、權限錯誤、WebDAV 回應錯誤和網路逾時。
  • PDF 能在瀏覽器打開但 Zotero 抓不到:出版社可能使用跳轉、短期簽名 URL 或需要先完成登入。可先在瀏覽器確認權限,再用 Connector 儲存頁面,不要只把 PDF 直接拖入資料庫。
  • 同步長時間停住:在 Clash Connections 搜尋 zotero 或同步服務的網域,看是否反覆出現 timeout。必要時先停用其他 VPN,再測試單一同步動作。

如果 Zotero 需要透過 HTTP 代理,應使用桌面系統或應用程式提供的代理設定,不要任意把帳號密碼寫進 Clash 設定檔。代理通道只負責傳輸,帳號憑證仍應由 Zotero 安全保存。完成設定後,先同步少量書目與一個小型附件,確認正常後再進行大量資料整理。

Overleaf 編譯與協作連線

Overleaf 不只是載入一個網頁。編輯器需要持續的即時協作連線,檔案面板需要讀取專案資源,編譯請求會交給遠端服務處理,登入還可能經過第三方身分驗證。若只允許首頁網域通過,常見症狀是可以登入卻看不到專案、編輯器不更新,或按下 Recompile 後一直轉圈。

建議先將 overleaf.com 相關主網域放入同一策略群組,再按照 Connections 逐步補足實際使用到的網域。不要把所有 WebSocket 或 CDN 網域一概設為直連或代理,因為不同地區、不同帳號方案和不同專案可能使用不同端點。若編輯器載入後很快斷線,優先檢查代理節點是否支援長連線、系統時間是否正確,以及瀏覽器是否有擴充功能攔截 WebSocket。

本地 LaTeX 編譯與 Overleaf 遠端編譯是兩件事。Clash 只影響本機到 Overleaf 的連線,不會改變遠端編譯器的 TeX Live 版本、套件清單或編譯限制。遇到「編譯失敗」時,先看 Overleaf 的編譯日誌,區分是網路請求沒有完成,還是 LaTeX 原始碼、圖片路徑、套件版本或參考文獻錯誤。

以連線記錄判斷,不要只看瀏覽器提示

當 Overleaf 顯示離線或編譯無回應時,查看是否有新的連線記錄。完全沒有新記錄,可能是瀏覽器擴充功能、快取或應用程式自身問題;有記錄但命中 REJECT、DIRECT 或 timeout,才從 Clash 規則、節點和網路路徑繼續排查。

DNS、TUN 與研究資料安全

研究工作常同時使用瀏覽器、Zotero、Git、終端機和 PDF 閱讀器。若只開啟系統代理,不遵守系統代理的程式可能仍然直連;若需要讓多種應用程式使用同一套規則,可考慮開啟 mihomo 的 TUN 模式。TUN 會接管 IP 封包,但也會增加路由、DNS 和權限方面的變數,不建議在尚未確認基本規則前直接開啟。

DNS 解析結果會影響分流判斷。當網域解析被本地網路改寫,Clash 可能只看到錯誤 IP,導致學術網站被判為直連或無法建立 TLS。mihomo 常見的設定方向是使用內建 DNS、配合 fake-ip 或 redir-host,並以 dns-hijack 接管 TUN 下的 53 埠請求。不同網路環境對 fake-ip 的相容性不同,若某個校園內網、印表機或特殊資料庫異常,可針對該網域加入 fake-ip-filter 或改用直連測試,不要全域關閉 DNS 功能。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

tun:
  enable: true
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

研究資料的安全性同樣重要。論文草稿、未公開資料、研究參與者資訊和實驗結果不應因為排查網路而上傳到不明的轉換服務或線上工具。Clash 設定檔裡也不要公開訂閱連結、代理密碼、WebDAV 憑證或機構登入資訊。分享設定檔給同事前,應移除敏感欄位並確認規則沒有把內網網域誤送到外部節點。

一套可重複的排查流程

研究工作最怕在截止日期前反覆猜測。遇到 Scholar、Zotero 或 Overleaf 異常時,可以固定按照下面順序縮小範圍:

  1. 確認 Clash 用戶端正在運行,目前模式為 Rule,且 RESEARCH 策略群組已選擇可用節點。
  2. 在代理頁測試節點延遲,再用瀏覽器開啟一個不涉及帳號的測試頁面,排除節點本身不可用。
  3. 在 Connections 搜尋目標服務的網域,觀察命中的規則、最終策略、連線狀態和錯誤訊息。
  4. 若命中 DIRECT,補充精確的 DOMAIN 或 DOMAIN-SUFFIX 規則;若命中 REJECT,檢查規則集順序與廣告過濾規則;若 timeout,測試節點、DNS 和網路環境。
  5. 關閉瀏覽器代理擴充功能、其他 VPN 和系統 PAC,避免多個代理層同時改寫請求。
  6. 只改一項設定後重新測試,並記錄修改前後結果。問題解決後,把有效規則整理到覆寫設定或自己的設定檔,避免下次更新訂閱時遺失。

最終的理想狀態不是「所有網站都走代理」,而是學術搜尋、授權資料庫、文獻同步和遠端寫作能穩定完成,本地服務與機構內網仍保持可用,而且每一條路由都能從 Connections 和 Logs 找到依據。先建立清楚的分流邊界,再按實際網域補規則,通常比長期使用全域模式更容易維護。

下載適合研究流程的 Clash 用戶端

需要 TUN、規則分流或 mihomo 核心功能時,可先查看各平台用戶端的差異,再依作業系統選擇合適版本。

下載 Clash 查看設定教學
下載 Clash

下載 Clash 用戶端

下載頁依平台列出各款用戶端,現役版本全都內建 mihomo 核心,裝好後匯入訂閱即可使用。

下載Clash 查看教學
下載Clash