對研究人員而言，代理工具的價值不只是「能不能開啟某個網站」，更在於能否穩定完成一整套工作流程：搜尋文獻、開啟摘要頁、下載 PDF、查看引用資料，再把 DOI、BibTeX 或全文匯入文獻管理工具。Google Scholar、arXiv 與 IEEE Xplore 的網域結構和資源載入方式並不完全相同，如果只設定一個首頁域名，常會出現搜尋結果能開啟、PDF 卻載入失敗，或頁面可以顯示但驗證、引用匯出功能異常的情況。

本文以 Clash 與 Mihomo 為主，整理研究工作中常見的分流策略、DNS 設計、TUN 模式和故障排查方法。你可以將這些設定加入現有配置，也可以先建立一個獨立的研究用策略組。文中的域名規則不代表任何服務的固定政策；網站可能調整架構，因此實際使用時仍應透過 Clash Dashboard 的連線記錄確認命中結果。

研究工作流程與代理需求

學術資料庫通常不是單一主機。以一次完整的文獻搜尋為例，瀏覽器可能先連線到 Scholar 的搜尋頁，再向 Google 的靜態資源、驗證服務或 googleusercontent.com 取得內容；點選結果後，還可能跳轉到出版社網站、機構登入頁或 PDF 儲存主機。arXiv 的摘要頁、HTML 文章、PDF 檔案與 API 服務也可能使用不同路徑。IEEE Xplore 則常見主站、內容服務、圖片資源以及 DOI 解析服務共同參與。

因此，設定研究用分流時，建議先區分三種需求：

  • 搜尋與瀏覽：需要穩定開啟 Scholar、arXiv 摘要頁和 IEEE Xplore 檢索頁，重點是 DNS 解析與 HTTPS 連線可靠。
  • 全文下載：PDF 可能來自不同子域名或外部儲存服務，不能只根據首頁域名判斷是否已完整配置。
  • 學術工具串接：瀏覽器擴充功能、Zotero、JabRef、命令列工具或 API 可能使用獨立網域，應透過連線記錄補充規則。
先觀察再擴大規則：不要一開始就把整個 Google 或所有外部網站都交給代理。先為明確的學術網域建立分流，使用 Clash 的連線頁觀察未命中的請求，再逐項補充，能減少誤代理和不必要的延遲。

如果你的主要工作是閱讀和下載論文，最實用的做法通常是建立一個名為「學術資料庫」的策略組，讓 Scholar、arXiv、IEEE 等明確域名統一走該策略組，而其他網站依照原本的規則處理。這樣既容易手動切換，也方便在節點品質變差時快速測試另一條線路。

Scholar、arXiv 與 IEEE 的網域分流

Clash 的域名規則常見有 DOMAIN、DOMAIN-SUFFIX 和 DOMAIN-KEYWORD。研究資料庫的規則優先推薦使用 DOMAIN-SUFFIX，因為它能匹配主域名及其子域名，範圍比關鍵字精確，也不容易誤傷其他不相關網站。例如 DOMAIN-SUFFIX,arxiv.org 可以覆蓋 www.arxiv.org、export.arxiv.org 等子域名。

服務建議域名用途設定說明
Google Scholarscholar.google.com搜尋論文、查看引用與相關文獻優先加入主域名，必要時依連線記錄補充資源域名
Google 內容服務googleusercontent.com部分預覽、快取或外部資源建議先觀察實際請求，避免無差別代理全部 Google 服務
arXivarxiv.org摘要頁、PDF、分類與搜尋使用後綴規則通常足以覆蓋主要子域名
IEEE Xploreieeexplore.ieee.org論文搜尋、摘要與全文頁直接加入 Xplore 主站，命中範圍較精準
IEEE 相關服務ieee.org登入、會員、部分跳轉或附屬內容若主站規則不足，再考慮擴大到 IEEE 主域名
DOI 解析doi.org由 DOI 跳轉到出版社頁面是否代理取決於目標出版社和網路環境

下列規則可以作為起點。策略組名稱必須與你的 proxy-groups 中實際名稱完全一致；如果你的配置使用「自動選優」或訂閱提供的策略組，請替換範例中的名稱。規則順序也很重要，研究網域規則應放在通用規則之前，否則可能先被 GEOIP,CN,DIRECT、MATCH,DIRECT 或其他廣泛規則截走。

研究資料庫分流規則
# Google Scholar
- DOMAIN-SUFFIX,scholar.google.com,學術資料庫
- DOMAIN-SUFFIX,googleusercontent.com,學術資料庫

# arXiv
- DOMAIN-SUFFIX,arxiv.org,學術資料庫

# IEEE Xplore 與 IEEE 相關服務
- DOMAIN,ieeexplore.ieee.org,學術資料庫
- DOMAIN-SUFFIX,ieee.org,學術資料庫

# DOI 解析服務，可依實際需求保留
- DOMAIN-SUFFIX,doi.org,學術資料庫

# 其他規則應放在學術網域之後
- GEOIP,CN,DIRECT
- MATCH,PROXY

DOMAIN-SUFFIX,ieee.org 的範圍比 DOMAIN,ieeexplore.ieee.org 大，可能涵蓋登入、會員、新聞或其他不需要代理的內容。如果你希望最小化代理範圍，可以先只加入 Xplore 主站；當登入或全文請求在連線記錄中顯示為其他 IEEE 子域名時，再針對該域名新增規則。

動手設定研究用策略組

完成域名規則之前，需要先準備一個可用的策略組。對研究工作而言，速度不一定是唯一指標；穩定性、長時間下載不斷線、HTTPS 握手成功率和不同網站的相容性同樣重要。建議至少放入兩個不同地區或不同線路的節點，並保留手動選擇能力，方便比較。

  1. 在 Clash Verge、Clash Verge Rev 或 Mihomo 的配置管理介面中開啟目前使用的 YAML 檔案，先備份原始配置。
  2. 在 proxy-groups 中建立「學術資料庫」策略組，將穩定的節點或既有的自動選優策略組加入其中。
  3. 在 rules 中貼上 Scholar、arXiv、IEEE 和 DOI 規則，並放在通用規則之前。
  4. 重新載入配置，不一定需要完全重啟客戶端；若介面提供「更新配置」或「重載配置」，優先使用該功能。
  5. 依序開啟 Scholar 搜尋頁、arXiv 摘要頁、arXiv PDF、IEEE Xplore 摘要頁和一個 DOI 連結。
  6. 在 Dashboard 的「連線」頁檢查每個請求的命中規則、使用策略組和實際節點，確認沒有被後面的通用規則覆蓋。
學術資料庫策略組範例
proxy-groups:
  - name: 學術資料庫
    type: select
    proxies:
      - 自動選優
      - 節點-HK
      - 節點-JP
      - DIRECT

加入 DIRECT 作為測試選項很有用。它不表示所有學術網站都應該直連，而是讓你快速比較「代理節點問題」和「本地網路問題」。如果代理模式下 Scholar 正常、直連模式下逾時，問題多半與目前網路路徑或 DNS 有關；如果兩種模式都失敗，則應檢查瀏覽器快取、系統時間、網站驗證或服務本身的狀態。

在 TUN 模式下，桌面應用程式和非瀏覽器工具的流量也能被 Clash 接管，這對 Zotero、命令列下載工具和文獻管理軟體很有幫助。但不同客戶端對 TUN、系統代理和 DNS 接管的支援方式不同，請以你所用版本的介面為準。若只是瀏覽器研究，先使用系統代理驗證規則，確認有效後再開啟 TUN，排查會更容易。

DNS、TUN 與 PDF 下載穩定性

很多「搜尋頁能開、PDF 下載失敗」的問題，並不是節點頻寬不足，而是域名解析和代理路由不一致。瀏覽器可能先用本地 DNS 解析出一個不適合目前網路的 IP，接著 Clash 只能看到 IP 連線，無法依照原始域名正確套用規則。對支援 Mihomo 的環境，fake-ip 通常更適合需要精確域名分流的研究場景。

研究場景 DNS 基本模板
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    domain:
      - +.google.com
      - +.arxiv.org
      - +.ieee.org
      - +.doi.org

這段配置只是通用示例，不應不加檢查地覆蓋訂閱提供的完整 DNS 設定。部分客戶端會自動生成 DNS 欄位，部分核心則對 DoH、DoT、fake-ip-filter 和 nameserver-policy 有不同支援程度。若改完後本地網域、校園網資源或印表機失效，應先檢查是否需要將 *.lan、*.local 和內部域名加入 fake-ip-filter，而不是直接關閉整個 DNS 接管。

PDF 下載還有幾個容易忽略的因素：

  • 下載請求可能是新連線：即使摘要頁走對了策略組，PDF 連結也可能跳轉到另一個域名，必須在連線記錄中確認。
  • 大型檔案更容易暴露線路問題：小型 HTML 請求成功，不代表節點能穩定維持數十秒或數分鐘的下載。
  • 瀏覽器續傳可能改變請求：重新下載時可能使用 Range 請求；若節點或上游服務對續傳支援不佳，可嘗試重新建立連線。
  • 不要忽略本地安全軟體：防毒軟體、企業代理、校園網認證和瀏覽器擴充功能都可能攔截 HTTPS 或修改下載行為。
不要盲目開啟 skip-cert-verify：如果 PDF 頁面出現憑證錯誤，先檢查系統日期、根憑證、節點域名和中間代理。將 skip-cert-verify 設為 true 會降低 TLS 驗證安全性，不應作為一般排錯的第一選項。

常見問題與排錯順序

研究資料庫故障通常具有「部分成功」的特徵：搜尋可用但下載不可用、摘要可見但引用匯出失敗，或一台裝置正常而另一台裝置失敗。遇到問題時，不要一次修改節點、DNS、TUN 和規則，否則很難知道哪項變更真正有效。建議按照「域名、規則、DNS、節點、應用」的順序逐層確認。

Scholar 搜尋頁無法開啟

先確認 scholar.google.com 是否在連線列表中出現。如果完全沒有連線記錄，可能是瀏覽器沒有使用 Clash 代理，或頁面被快取直接呈現；如果有記錄但命中 DIRECT，檢查規則順序及策略組名稱；如果已命中代理仍然逾時，切換另一個節點並測試 DNS。不要立刻把整個 google.com 加入規則，因為這會把大量與研究無關的服務一併交給代理。

摘要頁正常但 PDF 失敗

在 PDF 連結上按右鍵複製網址，查看它的主域名和是否存在跳轉。接著開啟 Clash 的連線頁，重新點擊下載，觀察實際出現的域名。若 PDF 來自 arXiv，通常應看到與 arxiv.org 相關的請求；若來自出版社或機構儲存服務，則需要針對該來源設定合理規則。對於不熟悉的第三方域名，先確認它確實屬於目前文章的合法下載來源，再決定是否加入代理清單。

IEEE 登入或引用匯出異常

IEEE Xplore 可能涉及登入、Cookie、驗證和跨域跳轉。先確認瀏覽器沒有阻擋第三方 Cookie 或 JavaScript，再檢查 ieeexplore.ieee.org 與其他 IEEE 子域名是否使用不同策略組。如果校園或機構提供圖書館代理，Clash 不應取代機構的合法登入流程；應保留機構認證所需的跳轉和 Cookie，並遵守學校與資料庫的使用條款。

Zotero 或命令列工具無法取得資料

瀏覽器能用不代表其他應用程式也會自動使用相同代理。系統代理、環境變數代理和 TUN 接管是三種不同層次。可以先在工具中設定 HTTP 或 SOCKS5 代理，或暫時開啟 TUN 測試。如果工具請求的是 API、DOI 或出版社域名，應從連線記錄取得實際域名，而不是只複製瀏覽器網址列的網域。

常見問題 FAQ

是否應該把所有 Google 網域都走代理？

通常不需要。研究用途可先處理 scholar.google.com，再依照實際連線記錄補充 googleusercontent.com 或其他必要資源。把所有 Google 服務交給同一策略組，可能增加流量、降低速度，也會讓問題更難定位。規則越精準，後續維護越簡單。

arXiv 只設定 arxiv.org 夠不夠？

多數瀏覽和 PDF 下載場景下，DOMAIN-SUFFIX,arxiv.org 已能覆蓋主要服務。若某個 API、鏡像或外部檔案來源仍然失敗，請先在 Clash 連線頁查看未命中的實際域名，再針對該域名補充規則。不要僅憑猜測加入大量關聯域名。

學術網站可以設定成 DIRECT 嗎？

可以作為測試或在你的網路環境中確實穩定時使用，但不應假設所有地區和所有資料庫都適合直連。代理與直連的差異可能來自 DNS、路由、驗證和節點品質。建議保留可切換策略組，根據實際延遲、下載穩定性和服務條款選擇。

開啟 TUN 後反而無法使用文獻工具，怎麼辦？

先暫時關閉 TUN，使用系統代理測試瀏覽器和工具，再確認問題是否只在 TUN 出現。接著檢查 DNS 接管、IPv6、虛擬網卡權限與系統防火牆。若只有校園網、內部資料庫或本地服務失效，通常需要在 fake-ip-filter、路由排除或直連規則中加入相應的內部域名，而不是更換所有節點。

一套好用的研究代理設定，重點不是堆疊大量域名，而是讓每個請求都能被看見、被解釋並且容易調整。先建立精準的 Scholar、arXiv 與 IEEE 分流，再透過 DNS 和 TUN 解決域名識別問題，最後用連線記錄驗證 PDF、DOI 和文獻工具的實際請求。完成這些基礎設定後，搜尋、閱讀與整理文獻的流程會穩定許多，也能把更多時間留給真正的研究工作。

立即開始

用 Clash 掌控您的流量

支援 Windows、macOS、Linux、Android 與 iOS，靈活規則，開箱即用。

免費下載 查看設定指南 →