科研工作离不开稳定的信息检索与资料获取环境。无论是使用 Google Scholar 查找相关论文、在 arXiv 跟踪预印本，还是通过 IEEE Xplore 阅读会议论文与期刊文章，网络波动、DNS 污染、跨域跳转失败和下载连接中断，都可能打断检索、阅读与文献整理流程。本文以研究者的日常工作流为背景，介绍如何使用 Clash 或 Mihomo 为学术网站设置清晰的分流规则，并配合 DNS、浏览器和文献管理工具，建立更稳定、可排查的科研网络环境。
科研访问中的常见网络问题
学术网站的访问体验往往比普通网页更复杂。一个论文页面可能同时加载搜索接口、验证码服务、静态资源、PDF 文件服务器、引用导出接口和第三方统计脚本。这些域名未必属于同一个主域名，因此只给 scholar.google.com 设置代理，并不一定能保证搜索结果、PDF 链接和跳转页面都正常工作。
Google Scholar 常见的问题包括搜索页面加载缓慢、验证码频繁出现、点击文献后的跳转超时，以及学校仓储或出版商页面打不开。arXiv 的问题更多集中在 PDF 下载、HTML 版论文、作者页面和 API 请求上。IEEE Xplore 则可能涉及 ieeexplore.ieee.org、数字对象标识符跳转、机构登录页面以及静态文件域名。遇到这些情况时，单纯更换浏览器通常效果有限，因为根本原因可能在 DNS 解析、代理规则或节点线路。
建议先区分三种故障：域名无法解析、连接建立但速度很慢、页面能打开而 PDF 或登录跳转失败。前两类通常与 DNS 和代理线路有关，第三类则要检查相关域名是否被错误地分到直连、浏览器是否阻止了跨站 Cookie，以及机构认证流程是否需要保持 IP 或会话一致。
| 现象 | 优先检查项 | 常见处理方式 |
|---|---|---|
| 搜索页面打不开 | DNS、主域名规则、节点可用性 | 启用 fake-ip，确认学术域名走代理 |
| 结果页正常但 PDF 失败 | 下载域名、重定向域名、连接超时 | 查看 Dashboard 连接记录，补充规则 |
| 机构登录反复跳转 | Cookie、IP 变化、浏览器隐私设置 | 固定策略组，避免同一会话频繁切换节点 |
| 页面打开速度忽快忽慢 | 节点质量、测速地址、策略组类型 | 使用 url-test 或 fallback 策略组 |
| 只有某台设备异常 | 系统代理、TUN、IPv6、浏览器缓存 | 逐层关闭功能进行对比测试 |
为学术网站设计分流策略
科研场景不建议把所有流量都交给代理。全局代理虽然简单，却可能让国内校园网、实验室内网、学校认证页面和本地文献管理服务变慢。更稳妥的方式是建立一个单独的「学术访问」策略组，只将需要稳定连接的域名交给代理，其余流量继续按照常规规则处理。
域名规则通常分为三层。第一层是明确的主域名，例如 scholar.google.com、arxiv.org 和 ieeexplore.ieee.org；第二层是相关子域名，使用 DOMAIN-SUFFIX 可以覆盖同一服务下的多个入口；第三层是论文下载或身份认证过程中出现的外部域名，这些域名不要凭猜测大量加入，应该通过连接日志确认后再补充。
proxy-groups: - name: 学术访问 type: select proxies: - 自动选择 - 稳定线路 - DIRECT rules: - DOMAIN-SUFFIX,google.com,学术访问 - DOMAIN-SUFFIX,googleusercontent.com,学术访问 - DOMAIN-SUFFIX,arxiv.org,学术访问 - DOMAIN-SUFFIX,ieee.org,学术访问 - DOMAIN-SUFFIX,ieeexplore.ieee.org,学术访问 - DOMAIN-SUFFIX,doi.org,学术访问 - MATCH,默认策略
上面的配置是一个起点，而不是完整的万能列表。DOMAIN-SUFFIX,google.com 会覆盖 Google 旗下多个子域名，范围较大，可能让普通 Google 服务也进入学术策略组。如果你希望控制得更细，可以改用多个 DOMAIN 规则，只覆盖实际需要的入口。对于 DOI 跳转，doi.org 可能把请求转到不同出版社，因此应观察最终连接，并根据实际情况决定是否继续走代理。
策略组的选择也很重要。日常阅读适合使用 select，方便手动选择稳定节点；节点数量较多时，可以在上层建立 url-test 自动选择延迟较低的线路；如果你更重视论文下载不中断，可以使用 fallback，让主节点失效时自动切换备用节点。
配置 DNS，避免解析污染
学术网站访问失败时，DNS 往往是最容易忽略的环节。浏览器在连接 Google Scholar 或 arXiv 之前，必须先获得域名对应的 IP。如果系统 DNS 返回错误结果、解析超时，或者浏览器使用了与 Clash 不同的 DoH 服务，就会出现「代理已经开启但网页仍打不开」的现象。
在 Mihomo 环境中，fake-ip 通常更适合域名分流。它先为应用返回一个虚拟地址，再由 Mihomo 根据域名进行规则匹配和后续解析。这样可以避免因为真实 IP 变化或 DNS 污染导致域名规则失效。对于局域网设备、打印机、校园内网域名和部分依赖真实地址的应用，则应加入 fake-ip-filter。
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 ipcidr: - 240.0.0.0/4 fake-ip-filter: - '*.lan' - '*.local' - 'localhost'
如果使用 Clash Verge 或 Clash Verge Rev，可以在配置文件中修改 DNS，也可以先通过界面确认当前核心是否支持对应字段。不同核心对 DoH、DoT、TUN 和 fake-ip 的支持细节可能不同，配置导入后应查看日志，确认没有出现未知字段或启动失败。Clash for Windows、ClashX 和 Clash for Android 的界面名称也可能不同，但排查思路一致：确认 DNS 请求是否由 Clash 接管，确认学术域名是否命中预期规则。
动手配置与验证科研工作流
配置不要一次改动太多，否则出现问题后很难确定是哪一项导致的。建议准备一个独立的配置副本，并按照「导入节点—建立策略组—添加规则—启用 DNS—逐项验证」的顺序操作。
- 备份当前配置。将正在使用的 YAML 文件复制一份，保留原来的策略组和 DNS 设置。不要直接在唯一配置上大范围修改。
- 确认节点可用。先在 Dashboard 中测试节点延迟，再用浏览器访问一个普通 HTTPS 网站，确认代理本身没有问题。
- 新建学术策略组。策略组名称可以使用中文，例如「学术访问」，并加入一个稳定节点、一个自动测速组和
DIRECT作为对照。 - 添加最小规则集。先加入 Google Scholar、arXiv、IEEE Xplore 和 DOI 主域名，不要一开始就添加大量不确定的第三方域名。
- 重载配置并观察日志。在 Clash Verge 或 Mihomo Dashboard 中重新加载配置，确认 YAML 缩进正确，规则数量和策略组名称均正常。
- 按工作流逐项测试。依次测试关键词搜索、打开论文详情、下载 PDF、复制 DOI、导出 BibTeX 或 RIS，以及跳转到出版社页面。
- 记录异常域名。如果搜索正常而 PDF 失败，查看连接列表中最后几个域名，再只为确有必要的域名补充规则。
# 1. 基础连通性 访问普通 HTTPS 网站 → 确认节点可以正常出站 # 2. 学术入口 scholar.google.com arxiv.org ieeexplore.ieee.org # 3. 论文资源 打开论文详情 → 点击 PDF → 等待下载完成 # 4. 文献整理 测试 DOI 跳转 → 导出 BibTeX/RIS → 导入文献管理软件
测试时尽量固定同一个节点，不要一边切换节点一边判断规则是否生效。某些机构登录流程会把会话与出口 IP、Cookie 或短时间内的访问行为关联起来，频繁切换节点可能造成重新登录或验证失败。科研下载也不建议使用极不稳定的高速节点，因为论文 PDF 通常比普通网页更大，短暂断连就可能导致下载校验失败。
浏览器与文献工具协同设置
Clash 负责网络层转发，但浏览器和文献工具自身的行为也会影响结果。浏览器如果启用了独立的安全 DNS，可能绕过系统代理的 DNS 逻辑；如果配置了单独的代理扩展，又可能覆盖 Clash 的系统代理设置。出现规则不生效时，应暂时关闭重复的代理扩展和浏览器 DoH，先使用单一代理入口进行验证。
Google Scholar 适合用来发现文献和追踪引用关系，arXiv 适合获取预印本和作者最新成果，IEEE Xplore 更适合检索工程、电子、计算机和通信领域的正式出版物。建议不要把三者简单视为同一类资源，而是分别设置书签、搜索关键词和文献保存流程。例如先在 Scholar 中确认主题与高被引论文，再到 arXiv 查找更新版本，最后通过 DOI 或标题到 IEEE Xplore 核对正式出版信息。
与 Zotero、EndNote 或 JabRef 配合时，优先测试网页端的 BibTeX、RIS 和浏览器识别功能，而不是一开始就批量导入。浏览器插件通常会同时请求页面、元数据和封面图片，若其中一个域名被错误直连，可能出现标题已保存但作者、期刊或附件缺失的情况。对于 PDF 附件，建议先在浏览器中确认文件能够完整下载，再让文献管理工具接管自动保存。
| 工具或功能 | 推荐做法 | 出现异常时检查 |
|---|---|---|
| 浏览器搜索 | 使用系统代理，关闭重复代理扩展 | 系统代理状态、浏览器 DoH、缓存 |
| Zotero Connector | 先保存元数据，再下载附件 | 页面域名、插件权限、Cookie |
| 命令行下载 | 使用明确的代理环境变量 | HTTP_PROXY、HTTPS_PROXY、证书错误 |
| 机构认证 | 固定节点，保持会话连续 | IP 变化、Cookie、登录重定向 |
故障排查与安全边界
如果 Scholar、arXiv 和 IEEE 都无法访问，先不要继续增加规则。先确认 Clash 核心正在运行，系统代理已经指向正确端口，并且当前策略组有可用节点。接着检查 DNS 是否启用、TUN 是否与系统代理重复接管，以及 IPv6 是否绕过了 IPv4 规则。部分网络环境会优先使用 IPv6，而节点或规则只处理 IPv4，这时可以暂时关闭 IPv6 进行对照测试。
如果只有 IEEE PDF 下载失败，可以在 Dashboard 的连接页面查看完整域名链路。论文页面可能通过 DOI、出版社、机构代理或内容分发网络跳转，最终下载地址不一定包含 ieee.org。此时应根据真实连接补充规则，但不要把所有下载域名都永久加入代理，因为 CDN 地址可能变化，也可能承载与论文无关的内容。
安全方面，External Controller 不应暴露在公网。若使用 Dashboard 管理 Mihomo，建议将控制器绑定到 127.0.0.1，并设置随机密钥。不要在公共电脑上保存订阅链接、机构账号和长期 Cookie。科研资料中可能包含未公开数据、审稿稿件或项目内部信息，应避免通过来源不明的节点传输敏感内容，也不要为了下载论文关闭证书校验或安装未知根证书。
常见问题解答
是否需要开启全局代理？
通常不需要。为学术域名建立独立策略组，既能减少不必要的代理流量，也方便定位问题。只有在规则匹配复杂、应用不支持域名分流，或临时需要确认节点本身是否可用时，才适合短时间使用全局模式进行对照测试。
为什么页面能打开，但 PDF 下载失败？
页面和 PDF 可能来自不同域名，也可能经历 DOI 或出版社跳转。请打开 Clash 的连接记录，找到点击下载后新增的域名，确认它是否命中了学术策略组。同时检查下载是否被浏览器扩展拦截，以及节点是否在大文件传输过程中频繁断连。
fake-ip 会影响校园网或内网服务吗？
可能会。校园网认证、局域网设备和内部域名通常应排除在 fake-ip 之外。将 *.lan、*.local 以及学校实际使用的内网后缀加入 fake-ip-filter，再根据连接日志逐项验证，不要直接把所有内网地址交给代理。
如何选择学术访问节点？
不要只看延迟。论文检索更关注首屏响应，PDF 下载更关注持续带宽和稳定性，机构认证则关注出口 IP 是否频繁变化。可以使用 url-test 做初步筛选，再手动固定一个下载稳定、会话连续性较好的节点。
稳定的科研网络配置不在于堆叠大量规则，而在于让 DNS、策略组、浏览器和文献工具各司其职。先用最小规则集覆盖 Scholar、arXiv、IEEE Xplore 和 DOI，再通过连接日志补充真实出现的域名；同时保留直连路径、固定可靠节点，并遵守数据库授权与版权要求。完成这些设置后，检索、阅读、下载和整理文献的流程会更连贯，也更容易在出现异常时快速定位问题。