科研人員Clash配置指南：Zotero與Overleaf穩定訪問方案

科研工作流中的網路問題：為什麼單一代理模式不夠

對研究人員而言，網路穩定性並不是單純「網頁能不能打開」的問題。一次完整的研究工作，可能同時包含在 Google Scholar 或出版社網站檢索文獻、從學校圖書館入口進行身份驗證、使用 Zotero 同步書目資料與附件，再到 Overleaf 編輯論文、拉取 Git 儲存庫、下載 LaTeX 套件。這些服務的網域、登入方式、連線時間與資料量都不相同，因此把所有流量一律設成全域代理，或者把所有服務一律設成直連，都容易在某個環節產生新的故障。

例如，文獻搜尋頁面可能可以正常載入，但點進出版社全文時卻出現逾時；Zotero 的書目資料已經同步，附件卻停在等待中；Overleaf 編輯器可以打開，編譯時卻無法取得圖片或遠端套件。這些現象未必代表帳號或軟體損壞，常見原因是不同程序沒有使用同一個代理入口，或者 Clash 規則先被一條寬泛的直連規則匹配，導致實際出口與預期不一致。

本指南採用「先觀察、再分流、最後才擴大接管」的思路。你不需要一開始就啟用最複雜的 TUN，也不需要把整份訂閱設定檔改得難以維護。先確認流量是否進入 Clash，再針對實際出現的網域建立規則，最後使用 TUN 或應用代理補上特殊程序，通常更容易定位問題，也較不會影響校園內網、印表機、NAS 與其他本地服務。

先畫出工具流量地圖：Zotero、Overleaf 與學術服務

動手編輯規則以前，建議先列出自己的研究工具與使用情境。不要只按照軟體名稱猜測網域，因為 Zotero、Overleaf 或出版社平台往往會透過 CDN、身份驗證服務與第三方儲存系統完成工作。最可靠的方法，是在 Clash 的連線頁面中操作一次完整流程，記錄實際出現的目的地、目前策略、連線是否成功，以及請求是在桌面程式、瀏覽器還是終端機中發起。

這份流量地圖的目的不是建立一張永遠不變的網域清單，而是幫助你區分「服務本身失效」與「請求沒有走到預期出口」。研究平台更新後可能新增 CDN 或登入主機，因此遇到新問題時，應回到連線紀錄重新觀察，而不是直接複製幾年前的規則片段。

系統代理、應用代理與 TUN：科研場景應如何選擇

Clash 常見的三種接入方式各有責任範圍。系統代理主要影響會讀取作業系統 HTTP／HTTPS 設定的瀏覽器與應用程式；應用代理則是在 Zotero、IDE、Git 或其他工具內單獨填入本機代理地址；TUN 會在更低的網路層接管流量，對不理會系統代理的程序較有幫助，但同時也可能與學校 VPN、企業安全軟體及本地網路路由產生衝突。

一般建議先從規則模式加系統代理開始。這種方式的優點是範圍清楚，方便在連線紀錄中逐條檢查，也不會在你只想查一個資料庫時把印表機、校園檔案伺服器或內網管理介面一併送入代理。若 Zotero 沒有任何請求出現在 Clash，才檢查其應用代理欄位；若應用程式既不支援代理設定，流量又確實需要經過 Clash，再以 TUN 作為補充方案。

第一步：建立 Clash 基礎設定與安全邊界

先確認目前使用的設定檔是實際生效的設定，而不是訂閱更新後被覆蓋的草稿。檢查混合埠、HTTP 代理埠與 SOCKS 埠是否已知，並確認系統代理指向同一個本機入口。若你同時使用其他 VPN、另一套 Clash 用戶端或校園安全連線工具，應先記錄它們的啟動順序與路由責任，避免多個程式同時搶佔預設路由。

科研場景還需要特別保護本地資源。校園印表機、內網資料庫、實驗室 NAS、遠端桌面與學校 VPN 通常不應被無條件送到外部節點。你可以保留既有的區域網路直連規則，並把需要代理的學術服務規則放在寬泛規則之前。若設定檔由訂閱自動更新，優先使用覆寫、Merge 或本機自訂規則功能，不要每次更新都手動修改整份檔案。

以下只是代理入口的示意，埠號必須依你的 Clash 設定替換。不要直接假設所有裝置都使用同一個埠，也不要把帶有帳號密碼的訂閱連結或私人節點資訊貼入公開問題回報。

# Example only — use the port configured by your Clash client
export HTTP_PROXY=http://127.0.0.1:7897
export HTTPS_PROXY=http://127.0.0.1:7897
export ALL_PROXY=socks5://127.0.0.1:7897

# Keep local services outside the proxy when appropriate
export NO_PROXY=localhost,127.0.0.1,::1,.local

第二步：配置 Zotero 同步、附件與 WebDAV

Zotero 的「同步成功」其實包含幾種不同工作。書目資料同步通常只是文字與索引資訊，速度快且容易完成；附件同步則可能涉及大量 PDF、圖片與壓縮檔，對節點穩定性、長連線與儲存服務的相容性要求更高。如果你使用 WebDAV 管理附件，還會多出另一組伺服器網域，不能只根據 Zotero 官方頁面建立規則。

1. 先在 Clash 中清空或篩選連線列表，於 Zotero 設定頁手動執行一次書目同步，記錄出現的目的地、策略與錯誤訊息。
2. 再測試單一附件下載或上傳，不要同時啟動整個資料庫同步，這樣才能分辨是認證問題、檔案儲存問題還是代理連線問題。
3. 若 Zotero 支援應用程式代理設定，填入 Clash 的 HTTP 或 SOCKS 入口，並重新啟動 Zotero，確認新的請求確實出現在連線列表。
4. 如果程式完全不讀取代理設定，先確認 TUN 是否能捕捉其流量，再檢查 DNS 模式、系統權限及安全軟體是否阻擋虛擬網卡。

規則撰寫時，建議把「觀察到的完整網域」放入自訂規則，而不是一開始就把所有雲端儲存服務的巨大後綴全部代理。過度寬泛的 DOMAIN-SUFFIX 可能讓本來應直連的檔案、校園入口或本地服務改走遠端，造成速度變慢，甚至觸發學校帳號的異常登入通知。

若同步顯示成功但附件仍失敗，可以比較兩次連線的大小、持續時間與策略。小型書目請求很快完成，不代表大檔案傳輸沒有中斷；節點對長連線的支援、連線重試機制與儲存端限制，都可能讓附件同步在幾分鐘後才報錯。此時應先換一個穩定節點進行 A／B 測試，而不是連續點擊同步按鈕造成更多重試。

Zotero 常見異常與排查順序

• 完全沒有連線紀錄：檢查 Zotero 是否在另一個使用者權限下執行，或是否被防火牆阻止；接著才考慮 TUN。
• 書目成功、附件失敗：分開檢查附件儲存服務、WebDAV 伺服器與大檔案連線，不要只測試登入頁。
• 同步不斷重試：暫停其他高流量下載，換節點並觀察是否為 DNS、TLS 或遠端服務回應碼問題。
• 多台電腦資料不一致：先確認使用的是同一 Zotero 帳號與資料庫，再排查代理；代理通常不會直接造成書目合併邏輯錯誤。

第三步：配置 Overleaf 登入、編輯與編譯流量

Overleaf 是瀏覽器主導的協作平台，但它並不只有一個簡單的網頁請求。登入可能經過身份驗證頁面，編輯器需要持續的即時連線，專案內容與編譯結果又會產生另一批請求。當瀏覽器用了系統代理、SSH 終端卻使用另一條路徑時，常會出現「網頁能開，Git 或編譯相關操作不正常」的情況。

建議先用無痕視窗或乾淨的瀏覽器分頁測試登入，並在 Clash 連線列表中觀察登入、編輯與編譯三個階段。若登入頁面出現但編輯器一直載入，可能是即時連線被錯誤分流；若編輯器正常但編譯報錯，則必須同時查看 Overleaf 專案的 LaTeX 日誌，因為檔案缺失、套件版本、語法錯誤與編譯時間限制都可能造成相同的表面現象。

對長時間編譯的論文，節點的穩定性比瞬間速度更重要。不要只用延遲測試最低的節點判斷品質，應實際進行一次小型編譯，再進行包含圖片、參考文獻與 BibTeX 的完整編譯。若不同節點表現差異很大，可以把 Overleaf 相關規則指定到一個可手動切換的策略群組，方便在高峰時段更換出口，而不必修改正文或重新匯入設定檔。

Overleaf Git 與終端機代理的差異

如果你使用 Overleaf 的 Git 整合，終端機中的 Git 不一定會遵循瀏覽器或系統代理。HTTPS Git 可以透過 Git 設定或環境變數指定代理；SSH Git 則涉及獨立的 SOCKS、ProxyCommand 或跳板設計。請先確認專案提供的連線方式，再決定採用哪一層代理。不要把 SSH 代理設定誤套用到 HTTPS，也不要在公共電腦上長期保存包含認證資訊的代理命令。

# HTTPS Git example; replace the local port as needed
git config --global http.proxy http://127.0.0.1:7897
git config --global https.proxy http://127.0.0.1:7897

# Inspect current Git proxy settings
git config --global --get-regexp 'http.*proxy'

測試完成後，如果該設定只為某個研究專案臨時使用，可以改成倉庫級設定，或在工作結束後移除全域代理。全域 Git 代理可能影響公司內部 Git、學校 GitLab 與本地伺服器，甚至導致本來能直連的程式碼拉取速度下降。

第四步：規則順序與 DNS 是最容易忽略的細節

Clash 規則通常按照從上到下的順序匹配。你為 Overleaf 或某個學術資料庫寫了精確規則，但它放在一條更早匹配的廣泛規則後面，就不會產生預期效果。常見的錯誤包括：大型規則集先把網域判定為直連、GEOIP 規則根據解析出的地址作出錯誤判斷，或者自動更新的 Rule Provider 蓋掉了本機覆寫。

建議把規則分成三層理解：第一層是本機與校園內網，第二層是需要指定出口的學術及協作服務，第三層才是一般網站、地區規則或兜底策略。科研網域的精確規則應位於會廣泛匹配它們的規則集之前。每次更新訂閱後，檢查覆寫是否仍然存在，並在 Clash 的規則命中資訊中確認真正生效的條目。

DNS 也會影響判斷結果。fake-ip、redir-host、IPv6 與不同 nameserver 的組合，可能使你看到的地址與預期不同。若規則看起來正確，但連線仍然逾時，可以暫時用簡化 DNS 設定作為 A／B 對照；不要同時改節點、模式、DNS、TUN 與規則，否則很難知道哪一項真正解決了問題。

第五步：用可重複的檢查表驗證配置

設定完成後，不要只測試首頁是否載入。研究工作的穩定性通常體現在一連串細節中，因此應按照固定順序進行驗證。先測試一般學術搜尋，再登入出版社或學校入口；接著測試 Zotero 書目同步、單一附件下載；最後在 Overleaf 開啟專案、修改一行文字、執行快速編譯及完整編譯。每一步都在 Clash 連線頁面記下目的地與策略。

1. 確認入口：系統代理、應用代理或 TUN 只保留一條主要測試路徑，避免多套工具同時接管。
2. 確認命中：在連線記錄中看到相關網域，並核對策略群組不是意外的 DIRECT 或錯誤節點。
3. 確認持續性：讓 Zotero 附件或 Overleaf 完整編譯持續數分鐘，觀察長連線是否會中斷。
4. 確認本地服務：列印、校園內網、NAS 與學校 VPN 仍可使用，確保分流沒有擴大到不必要的範圍。
5. 記錄變更：保存設定檔版本、規則調整、節點名稱與測試時間，方便日後比較或還原。

若測試失敗，先把問題分類。沒有連線紀錄通常是代理入口或接管方式的問題；有紀錄但策略錯誤，多半與規則順序有關；策略正確但請求逾時，才進一步檢查節點品質、DNS、IPv6、遠端服務狀態與帳號權限。這種分類比反覆切換全域模式更有效，也能避免為了修一個附件問題而破壞整台電腦的本地網路。

日常維護：讓研究環境保持可預期

科研專案往往持續數月甚至數年，因此一次能用的配置還不夠，還需要可維護性。建議將自訂規則與訂閱內容分開保存，為重要變更加上日期與原因，並在 Clash 用戶端更新或訂閱刷新後重新測試 Zotero 與 Overleaf。若實驗室多人共用一套文件，請只記錄必要的網域與策略，不要把私人節點、訂閱連結、帳號令牌或 Cookie 放入團隊 Wiki。

對研究資料而言，代理設定也屬於資訊安全的一部分。不要在不可信的公共節點上傳未公開論文、受限制的實驗資料或包含個人識別資訊的附件；確認服務的傳輸加密、帳號雙重驗證及機構資料政策。Clash 可以協助你控制路徑與觀察連線，但它不會自動替你判斷某個節點是否值得信任，也不會替代學校或研究機構的安全規範。

常見問題

Zotero 一定要開 TUN 才能同步嗎？

不一定。若 Zotero 可以使用應用代理，或者它遵循系統代理，規則分流通常已經足夠。TUN 的價值在於補足不支援代理設定的程序，或協助定位「流量根本沒有進入 Clash」的情況。開啟前應先確認虛擬網卡權限、DNS 及本地網路例外規則。

Overleaf 編譯失敗應該先換節點嗎？

不應直接把所有編譯錯誤歸因於節點。先看 Overleaf 編譯日誌，確認是否是 LaTeX 語法、參考文獻、圖片路徑或套件錯誤；若日誌顯示資源下載或連線逾時，再查看 Clash 連線記錄，最後才用另一個穩定節點作對照。

學術網站是否應該全部代理？

不建議。按照實際命中情況建立精確規則，能保留學校服務與本地資源的直連效率，也降低不必要的跨區登入。對需要代理的資料庫、出版社或協作服務指定策略即可，並定期檢查更新後的規則順序。

與只提供單一全域開關的工具相比，科研工作更需要能看見連線、調整規則並保留本地例外；有些簡化型代理工具雖然上手快速，卻可能無法細分 Zotero 附件、Overleaf 長連線與 Git 終端代理，也不容易處理校園 VPN 共存問題。Clash 的優勢在於 TUN、規則分流和應用代理可以按需組合，讓你先用最小範圍解決問題，再逐步擴大到真正需要接管的程序。如果你希望把文獻檢索、Zotero 同步與論文協作整理成一套可觀察、可還原的網路配置，從 Clash 的多平台用戶端開始會比反覆切換全域模式更容易維護。

立即免費下載 Clash，開啟流暢上網新體驗 →