前言：研究工作的網路需求
對研究人員而言，網路工具的價值不只是「能不能打開某個網站」，而是能否長時間、穩定地完成搜尋文獻、下載全文、同步引用資料，以及與合作者共同修改論文。Google Scholar、出版社資料庫、Zotero、Overleaf 和雲端儲存服務往往同時開啟，一旦其中某個環節頻繁超時或連線中斷，就可能打斷閱讀節奏，甚至造成引用資料重複、附件遺失或文件同步衝突。
Clash 的作用是把不同研究服務的流量分開處理：對可直接訪問的校園系統和本地服務使用 DIRECT，對需要較穩定國際路徑的學術搜尋、同步服務與線上寫作平台使用固定的代理策略。這種按用途分流的方式，比單純開啟全域代理更容易維持穩定，也能減少不必要的延遲。
本文的配置目標
讓學術搜尋、文獻管理與線上寫作使用清楚可控的分流規則；保留校園內網與本地服務的直連；在連線異常時能快速定位問題，而不是盲目更換所有設定。
1先規劃研究工作流與分流範圍
在修改 Clash 之前，建議先把研究流程拆成幾類。不同服務的連線特性並不相同，搜尋頁面需要穩定解析與快速載入，Zotero 更依賴 API、WebDAV 或雲端同步，Overleaf 則需要長時間保持登入狀態並頻繁傳輸小型請求。如果把所有流量都交給同一個節點，某個服務出現問題時，其他工作也會一起受到影響。
| 研究環節 | 常見服務 | 建議策略 | 主要考量 |
|---|---|---|---|
| 文獻搜尋 | Google Scholar、Crossref、出版社網站 | 學術代理組 | 解析穩定、頁面載入完整 |
| 引用管理 | Zotero、Zotero Storage、WebDAV | 固定節點或穩定代理組 | 同步不中斷、避免頻繁更換 IP |
| 線上寫作 | Overleaf、GitHub、雲端文件 | 寫作代理組 | 登入持久性、WebSocket 與附件上傳 |
| 校園資源 | 校內圖書館、VPN、內部入口 | DIRECT 或校園專用組 | 保留校內 IP 與低延遲 |
這裡的「代理組」不代表一定要使用特定地區的節點。實際選擇應以服務條款、研究機構的網路政策與節點穩定性為前提。若資料庫要求校園認證，Clash 不能取代合法的機構登入、圖書館代理或 VPN；它只負責依照你的網路環境轉送流量。
小撇步
先記錄「哪一個服務、哪一個時間、出現什麼錯誤」，再調整規則。研究期間最怕反覆改動設定卻沒有測試紀錄，最後無法判斷問題究竟來自節點、DNS 還是服務本身。
2Clash 基礎設定：模式、DNS 與節點
在 Clash Verge、Clash Verge Rev 或 Mihomo 客戶端中，先匯入可信來源提供的 YAML 設定檔，確認訂閱更新時間與規則版本正常，再開始調整。若只需要瀏覽器和桌面應用程式使用代理，可以先採用系統代理模式；若 Zotero、Overleaf 或其他應用程式沒有遵循系統代理，再考慮開啟 TUN 模式。
選擇適合的工作模式
- 規則模式：適合日常研究工作。Clash 會按照域名、IP 或規則集分流，能同時保留直連和代理。
- 全域模式：適合短時間測試某個服務是否能連線，不建議長期使用，因為校園內網、印表機和本地服務可能被送往代理節點。
- TUN 模式：適合需要接管未遵循系統代理的程式，但通常需要管理員權限，並可能與其他 VPN、端點防護軟體產生衝突。
DNS 設定的實用原則
學術網站常包含主站、登入服務、PDF 伺服器和 CDN。若 DNS 解析結果不穩定，可能出現首頁能開啟、PDF 卻下載失敗的情況。使用 Mihomo 時，可根據自己的網路環境啟用加密 DNS，並留意是否開啟了會影響本地域名的 fake-ip。校園網路若依賴內部域名，應使用 nameserver-policy 將校園域名交給校內 DNS，避免內部入口被錯誤解析。
上方只是結構示例，10.0.0.53 必須替換成你的機構 DNS；若沒有校園內部域名，不要直接照抄。修改後請重新載入配置，並使用日誌確認域名是否被正確解析。若開啟 fake-ip 後某個應用程式異常，可先將該域名加入 fake-ip-filter，再逐項測試，而不是立刻關閉所有 DNS 功能。
3建立學術網站分流規則
分流規則必須放在廣泛規則之前。例如 GEOIP,CN,DIRECT 或 MATCH,PROXY 若排在前面，可能讓學術服務在未完成域名匹配前就被處理。建議把自己實際使用的服務列入獨立規則集，並把策略組名稱寫得清楚，日後更換節點時不需要重新編輯大量規則。
搜尋與出版社服務
不要為了「看起來完整」而加入自己沒有使用過的域名。出版社可能將登入、全文和圖片放在不同子域名，遇到頁面載入不全時，應從 Clash 日誌找出實際請求，再用 DOMAIN-SUFFIX 補充。若某服務包含校園認證流程，請確認認證域名仍走機構要求的路徑，避免登入成功後返回頁面失效。
為學術服務建立獨立策略組
學術代理組最好不要使用頻繁切換節點的自動負載均衡。Google Scholar 的搜尋可以容忍短暫延遲，但登入、下載和資料庫檢索更需要連線的一致性。可建立一個包含兩至三個候選節點的手動組，平時固定使用一個節點，只有在延遲明顯升高、PDF 連續失敗或服務回傳網路錯誤時才切換。
請勿忽略使用規範
代理只能改善連線路徑，不能繞過資料庫訂閱、學校授權或出版社的存取限制。請使用合法帳號與機構提供的認證方式，也不要以自動化大量請求影響學術服務的正常運作。
4Zotero 文獻管理與同步配置
Zotero 的工作流通常包含三部分：書目資料擷取、條目與標籤同步、PDF 附件同步。這三部分不一定使用相同的網域，因此「瀏覽器可以開啟」並不代表 Zotero 已經能正常同步。第一次設定時，建議先在 Zotero 內手動同步，觀察 Clash 日誌中出現的域名，再補充規則。
Zotero 帳號與資料同步
- 開啟 Zotero 的同步設定，確認使用正確的帳號，並先備份本機資料庫。
- 在 Clash 中查看 Zotero 同步期間的連線日誌，辨認帳號服務、API 與儲存服務的域名。
- 將實際使用的 Zotero 域名放入固定策略組，避免同步過程中頻繁切換出口 IP。
- 先同步少量條目和附件，確認雲端資料完整後，再進行大批量同步。
若使用 WebDAV 儲存附件，請把 WebDAV 伺服器域名單獨列出，不要只依賴 Zotero 的通用規則。附件同步失敗時，先檢查儲存空間、帳號權限和 WebDAV 位址，再查看是否是代理節點對大檔案連線的支援不佳。PDF 下載很慢並不一定代表規則錯誤，也可能是伺服器限速或節點對長連線的表現不理想。
避免同步衝突
不要在多台電腦同時大量修改同一個 Zotero 資料庫，也不要在同步進行中強制關閉客戶端。先讓條目同步完成，再處理附件，可以降低衝突與重複檔案的機率。
5Overleaf 與協作寫作的穩定性
Overleaf 不只是靜態網頁，它還需要登入狀態、即時編輯請求、編譯任務和檔案上傳。若節點頻繁切換，可能出現編輯器重新連線、編譯結果延遲或協作者狀態消失。對需要長時間寫作的專案，建議為 Overleaf 使用與 Zotero 不同或相同的固定策略組，實際取決於哪一組節點對你的網路更穩定。
- 先以規則模式登入 Overleaf，開啟一個不含敏感資料的測試專案。
- 編輯一段文字並執行編譯，確認編譯日誌與 PDF 預覽都能正常更新。
- 上傳一張圖片或一個 BibTeX 檔案，檢查附件傳輸是否完整。
- 邀請合作者進入測試專案，觀察即時游標、留言和版本歷史是否穩定。
如果編輯器反覆顯示重新連線，先固定節點並暫時關閉瀏覽器擴充功能，再確認系統時間是否正確。若只有 PDF 預覽失敗，可能是編譯服務或專案本身的 LaTeX 錯誤；不要把所有編譯問題都歸咎於 Clash。研究資料也應遵循機構的資訊安全要求，未經允許不要把受限制的資料集、受試者資料或未公開稿件上傳到第三方平台。
6測試、排錯與日常維護
完成規則後，請採用「一次只改一項」的方式測試。先關閉代理確認直連結果，再開啟規則模式；接著測試 DNS、登入、搜尋、PDF 下載、Zotero 同步和 Overleaf 編譯。這樣可以分辨是服務無法使用、節點品質不足，還是本機設定造成的問題。
| 現象 | 優先檢查項目 | 處理方向 |
|---|---|---|
| 搜尋頁面能開但結果圖片不顯示 | 日誌中的 CDN 域名 | 補充實際使用的子域名規則 |
| Zotero 條目同步成功但附件失敗 | 儲存服務、WebDAV 與空間 | 分開測試附件域名與帳號權限 |
| Overleaf 持續重新連線 | 節點穩定度、WebSocket、瀏覽器擴充 | 固定節點並暫停干擾性擴充功能 |
| 校園網站無法登入 | 校園域名是否被代理、DNS 是否正確 | 加入校園域名直連或使用校方 VPN |
每次更新訂閱後，都應確認自訂規則仍然存在。有些客戶端會把手動修改直接寫入訂閱內容，更新後可能被覆蓋；更穩妥的方式是使用覆寫配置、規則提供者或客戶端支援的自訂規則檔。請定期備份 YAML、策略組與 DNS 設定，並記下目前可用的節點名稱，遇到服務異常時才能快速回復。
建議的最終檢查清單
學術搜尋能完成登入與檢索；PDF 可以完整下載；Zotero 條目與附件能分別同步；Overleaf 能編輯、編譯與協作；校園服務仍保留正確的直連或機構 VPN 路徑。
研究工作最需要的是可預期性，而不是單次測試中的最高速度。透過清楚的服務分類、固定的策略組、可追蹤的日誌與定期備份，Clash 可以成為研究工作流中的網路管理工具，協助你減少連線干擾，將注意力放回文獻閱讀、資料分析與論文寫作本身。