先盤點學術網站流量，再決定是否分流
研究工作常同時用到論文搜尋、出版商平台、預印本下載、文獻管理與協作寫作。這些服務不一定需要走同一條線路：Google Scholar 可能需要代理才能穩定載入搜尋結果；arXiv 的摘要頁與 PDF 下載可能走不同網域；IEEE Xplore 則可能受機構授權、帳號登入或出口 IP 影響。先確認哪個服務在哪種網路下有問題，比把所有學術網站一律送進代理更容易找到原因。
Clash 客戶端負責管理設定檔與系統代理，Clash 或 Clash Meta（mihomo）核心負責比對規則並選擇出口。系統代理或 TUN 決定應用程式的流量能否進入核心；規則決定流量進入後交給哪個策略組或直連。只新增網域規則，無法接管一個完全沒有使用系統代理、也沒有經過 TUN 的應用程式。
| 工作流程 | 可先檢查的網域 | 需要留意的差異 |
|---|---|---|
| Google Scholar 搜尋 | scholar.google.com | 搜尋頁面可載入，不代表 PDF 出版商頁面也可存取 |
| arXiv 預印本 | arxiv.org | 摘要頁、PDF 與外部引用連結可能走不同服務 |
| IEEE Xplore | ieeexplore.ieee.org | 代理不會提供機構訂閱或解除帳號授權限制 |
| Zotero、Overleaf | 依應用程式連線紀錄確認 | 同步、連接器、登入與協作可能使用不同端點 |
按服務設計規則，避免把整個 Google 都送進代理
分流可以先採取「明確網域、逐步補充」的方式。Scholar 搜尋頁可從 scholar.google.com 開始；若核心連線紀錄顯示頁面資源另行連到其他主機，再依實際需求增加規則。不要只因為 Scholar 屬於 Google，就直接將所有 google.com 或常見 Google 服務網域全部送入代理，否則 Gmail、雲端硬碟或其他服務也可能被一起改變出口。
arXiv 可先以 arxiv.org 作為檢查起點。若摘要頁能開啟但 PDF 下載失敗，先在客戶端的連線紀錄查看下載請求實際命中的網域、規則和策略組，再判斷是否需要增加網域。不要因為搜尋結果中的引用連結指向其他出版商，就把那個出版商網域假設成 arXiv 的下載主機。
IEEE Xplore 可先單獨測試 ieeexplore.ieee.org。如果文章頁可開啟但全文不可下載，請分辨這是網路連線失敗，還是帳號、機構授權或出版商存取限制。連線紀錄可以協助判斷請求是否進入核心、最後使用哪個策略；它不能證明使用者已獲得全文授權。
規則需要放在較寬泛的匹配規則之前，例如 MATCH，並指向目前設定檔中確實存在的策略組名稱。下方片段只示範規則方向；學術資料 必須是你已建立或即將建立的策略組，不能直接假設訂閱裡已有同名組。
rules:
- DOMAIN,scholar.google.com,學術資料
- DOMAIN-SUFFIX,arxiv.org,學術資料
- DOMAIN,ieeexplore.ieee.org,學術資料
- MATCH,原有預設策略DOMAIN 用於精確網域；DOMAIN-SUFFIX 可匹配該網域及其子網域。若要讓三種服務採取不同策略，可以分別建立策略組，或把規則出口改成現有的代理、直連策略。不要將範例中的 原有預設策略 當作可直接載入的實際組名；它必須替換為目前設定檔最後一條通用規則原本使用的出口。
動手操作：用 Scholar、arXiv 與 IEEE 驗證分流
測試時先固定網路、設定檔和節點，並一次只改一項。若同時切換系統代理、TUN、DNS 模式和策略組，即使問題消失，也很難知道是哪項設定造成差異。建議先關閉不必要的自動切換，並記下客戶端版本、核心版本、設定檔名稱與目前策略模式，之後較容易重現結果。
- 在 Clash 客戶端確認核心正在執行，並確認目前啟用的是要修改的設定檔。記下 HTTP、SOCKS 或 mixed 代理連接埠；若透過 TUN 測試，也記下 TUN 是否已啟用。
- 打開連線紀錄或連線面板，先清除或記錄現有項目，再分別開啟 Scholar 搜尋頁、arXiv 摘要頁與 PDF，以及 IEEE Xplore 的文章頁。每次只測一個服務，避免同時執行同步或大型下載。
- 對照每筆連線的目標網域、命中規則與最終策略。如果 Scholar 命中
MATCH而不是預期的學術策略組，先檢查規則順序、拼字與設定檔是否載入；若顯示直連但預期走代理，則檢查規則出口。 - 在策略組中手動選擇一個可用出口，重試同一個頁面或下載。再切換至
DIRECT比較結果；有些網路可能直連較穩定，有些則需要代理。選擇標準是服務是否可正常完成，而非只看單次節點測速數字。 - 確定結果後再測試自動策略組，並記錄切換前後的網域、命中規則和頁面狀態。若出現連線逾時，先確認核心是否記錄到請求，以及它選擇的出口；不要立刻加入大量不確定的網域規則。
測試 PDF 時，留意瀏覽器是否從出版商頁面跳轉到另一個網域。跳轉後的請求可能依照新網域重新比對規則，與最初的搜尋頁使用不同出口。若連線面板只顯示摘要頁成功，並不能據此判斷 PDF 下載也已經走過同一條路徑。
透過系統代理測試時，瀏覽器通常會讀取作業系統代理，但 Firefox 等瀏覽器可能使用獨立設定；擴充功能、PAC 或組織政策也可能覆寫系統設定。透過 TUN 測試時，請確認目標流量確實被導入虛擬網卡，且沒有被規則設為直連。這兩種測試入口不同，應分開驗證。
把 Zotero 與 Overleaf 納入工作流程檢查
Zotero 的使用情境不只有桌面程式同步。瀏覽器中的 Zotero Connector 會配合瀏覽器載入頁面並擷取文獻資訊；桌面程式還可能執行附件下載、資料同步與登入相關連線。若瀏覽器能開啟論文頁但 Connector 無法擷取，先檢查瀏覽器擴充功能狀態、桌面程式是否開啟，以及擴充功能與桌面程式之間的本機通訊，不要直接把問題歸咎於出口節點。
- 論文擷取：確認瀏覽器實際開啟的頁面可正常顯示，再觀察 Connector 是否能辨識文章欄位。若部分文章無法自動辨識，可先手動儲存 DOI 或以 DOI 匯入，不必為此放寬整個網站的分流範圍。
- 附件下載：在瀏覽器或 Zotero 內分別測試開啟文章頁與下載附件。出版社可能使用不同的內容主機；以連線紀錄中的實際網域為準，逐條補充規則。
- 同步：先確認 Zotero 帳號登入與服務狀態，再檢查桌面程式的同步錯誤訊息。代理切換可能影響新建立的連線；正在進行的同步工作不一定會無縫改走新出口。
Overleaf 的網頁編輯、登入與協作也可能依賴不同的網路請求。若編輯器主畫面可載入，但協作或編譯有異常，先查看瀏覽器開發者工具或客戶端連線紀錄中的失敗主機，再決定是否調整路由。將整個網域家族一律導向特定節點，可能讓原本正常的登入或協作服務改走另一個出口。
機構網路有時會以校園出口 IP 提供資料庫權限。若直接使用家中網路時能透過校園 VPN 取得全文，改用其他代理出口後可能失去這項識別條件。這時應依照圖書館或機構的正式存取方式設定，不要假設任何代理出口都能替代校園 VPN 或機構登入。
依症狀定位問題，讓規則容易維護
遇到連線異常時，先區分「請求沒有進入核心」、「進入核心後命中錯誤規則」與「出口已選擇但目標服務仍拒絕」三類情況。這三者需要不同處理方式：第一類檢查系統代理、瀏覽器代理設定或 TUN；第二類檢查規則順序及策略組名稱；第三類則要查看出口可用性、目標站服務狀態和帳號授權。
- 頁面完全無法開啟，連線面板也沒有該網域：檢查瀏覽器是否走系統代理、TUN 是否接管，以及瀏覽器是否使用獨立代理設定。
- 面板有連線，但命中不預期的規則：查看更早出現的網域規則或規則集，確認是否先被其他匹配條件攔截；再確認最後的策略組名稱與設定檔生效狀態。
- 命中預期策略但連線逾時：用同一出口測試不同頁面，並觀察核心日誌。只有在出口可連線、但特定網域仍失敗時，才進一步排查該服務的網域、TLS 或帳號限制。
- 搜尋結果正常，全文仍無法取得：確認全文連結實際前往的出版商、登入狀態與機構授權。Scholar 顯示結果不代表全文免費，也不代表全文主機和搜尋頁使用相同規則。
規則穩定後，建議保留一個清楚的學術策略組，並讓它包含手動選擇與直連選項，方便在校園、家庭或公共 Wi-Fi 等不同網路間切換。若使用 url-test 或 fallback，請記得健康檢查只測試設定中的網址，不等於確認 Scholar、arXiv、IEEE、Zotero 與 Overleaf 全部可用；需要固定出口的機構登入或長時間協作，也不宜只依賴自動切換。
最後，匯出或分享設定前，檢查其中是否包含訂閱網址、節點密碼、帳號憑證或控制 API 密鑰。學術分流規則通常不需要公開這些資訊。保留一份不含秘密資料的規則備份，並在更新客戶端或核心後重新確認規則仍被載入，可減少訂閱更新與版本變動造成的意外。