前言：科研工作流为什么需要精细分流
科研人员的网络需求通常比普通网页浏览更加复杂。一次完整的研究任务，可能同时包含使用 Google Scholar 检索论文、通过 arXiv 下载预印本、访问 IEEE Xplore 或出版社平台、在 Zotero 中同步文献和附件，最后还要在 Overleaf 中完成 LaTeX 写作与团队协作。这些服务的域名、连接方式和登录验证机制各不相同，如果所有流量都采用同一种连接策略，就容易出现搜索页面打不开、PDF 下载中断、Zotero 同步失败或 Overleaf 编译资源加载缓慢等问题。
Clash 的价值并不是简单地把所有流量都交给代理节点，而是根据目标域名、IP 地址和应用进程进行分流。科研相关站点可以统一交给一个稳定的学术策略组，国内数据库、校园门户和本地打印服务则继续使用 DIRECT。这样既能减少不必要的延迟，也能避免校园系统因出口地址变化而频繁要求验证。
本文以 Clash Verge、Clash Verge Rev 或其他支持 Mihomo 内核的客户端为例，介绍一套适合科研场景的配置思路。配置前请确认你所在机构的网络使用规定，并遵守论文数据库、出版社和代码托管平台的服务条款。代理配置只能改善连接路径，不能替代学校或研究机构提供的合法访问权限。
适合的目标
让 Scholar、arXiv、IEEE Xplore、Zotero 和 Overleaf 使用稳定且可控的连接，同时保留校园网、国内网站和常用本地服务的直连能力。
1先梳理科研工作流，再设计策略组
配置 Clash 之前，建议先把日常科研活动拆成几个连接场景。不同服务的最佳节点并不一定相同：文献检索重视 DNS 解析和网页加载速度，PDF 下载重视持续带宽，Zotero 同步重视长连接稳定性，而 Overleaf 则同时涉及登录、项目编辑、编译和图片资源加载。将所有站点放进一个随意命名的“国外网站”策略组，后续排查问题会非常困难。
| 科研场景 | 代表服务 | 主要要求 | 建议策略 |
|---|---|---|---|
| 文献检索 | Google Scholar、arXiv | 网页打开快、解析稳定 | Scholar-Research |
| 出版平台 | IEEE Xplore、ACM、Springer | 登录和 PDF 下载稳定 | Scholar-Research |
| 文献管理 | Zotero、WebDAV、云同步服务 | 长连接可靠、不要频繁切换出口 | Research-Sync |
| 在线写作 | Overleaf、GitHub | 编辑、编译和资源加载稳定 | Research-Write |
| 校园与本地服务 | 校园门户、图书馆内网、网银 | 保持本地网络身份 | DIRECT |
如果你的订阅中只有少量节点，可以先使用一个 Research 策略组；如果节点较多，则可按地区或线路质量建立三个组。科研服务不建议频繁使用随机负载均衡，因为短时间内改变出口 IP，可能触发登录验证、验证码或临时安全限制。对于 Zotero 和 Overleaf，宁可选择延迟稍高但稳定的节点，也不要一味追求测速页面上的最低延迟。
Scholar 与学术平台的域名规则
以下规则是常见的起点，实际域名可能因跳转、机构登录或出版社页面更新而变化。规则应放在通用的地区规则和兜底规则之前，否则可能被更宽泛的规则提前匹配。
规则不要照抄到底
出版社常常使用多个静态资源域名和第三方登录域名。遇到页面能打开但图片、验证码或 PDF 加载失败时，应通过 Clash 的连接日志确认真实请求域名，再补充最小范围的规则，而不是直接开启全局模式。
2动手配置：为 Zotero 与 Overleaf 建立稳定链路
下面是一套适合桌面端的实际操作流程。不同客户端的菜单名称可能略有差异，但核心步骤基本一致：导入订阅、确认策略组、添加科研域名规则、开启系统代理，最后根据需要启用 TUN 模式。
- 打开 Clash Verge 或 Clash Verge Rev，在「配置」页面导入你的订阅文件。确认文件能够正常解析，并且策略组中确实存在可用节点。
- 在「代理」页面为
Scholar-Research、Research-Sync和Research-Write选择节点。首次测试时建议手动固定同一个稳定节点，便于判断问题来源。 - 在配置文件的
rules区域加入科研域名规则，并确保这些规则位于GEOIP,CN,DIRECT或MATCH之前。 - 打开系统代理后，先用浏览器访问 Scholar、arXiv 和 Overleaf。确认网页、登录页面、静态图片以及 PDF 下载均能正常完成。
- 启动 Zotero，进入同步设置，分别检查文献元数据同步和附件同步。若使用 WebDAV，请将 WebDAV 服务域名单独加入
Research-Sync。 - 只有在浏览器测试正常、但 Zotero 桌面端或其他非浏览器应用仍无法连接时，再启用 TUN 模式，并授予客户端所需的系统网络权限。
Zotero 同步规则与排错思路
Zotero 的同步请求可能涉及官方同步服务、附件存储和 WebDAV。不要只根据软件名称添加规则，因为域名匹配规则处理的是网络请求，而不是所有应用流量。可以先观察 Clash 的连接记录，再针对实际出现的域名添加规则。常见的配置结构如下：
如果 Zotero 显示同步完成但附件没有上传，先检查 WebDAV 账户、存储配额和服务端状态，再检查 Clash 日志中是否存在连接重置。若元数据和附件都失败，可以暂时把该策略组固定到另一条线路进行对比。不要在短时间内反复切换多个节点并连续点击同步，这可能造成重复请求或进一步触发服务端限制。
Overleaf 的写作与编译连接
Overleaf 的项目编辑页面、实时协作、编译服务和外部图片资源可能使用不同域名。建议将 Overleaf 主站放入 Research-Write，而 GitHub、图床或外部数据源按照实际用途单独处理。若编辑器可以打开但编译一直停留在等待状态，先查看 Clash 是否将相关请求错误地分配到了 DIRECT，再检查节点是否支持稳定的 HTTPS 长连接。
3TUN、DNS 与常见故障排查
仅开启系统代理时，通常可以覆盖浏览器和支持 HTTP/SOCKS 代理的应用，但部分桌面软件、插件、命令行工具以及后台同步进程可能不会读取系统代理。此时可以考虑使用 TUN 模式。TUN 会创建虚拟网络接口，把更多系统流量交给 Clash 处理，适合 Zotero、Git、LaTeX 工具链等存在代理兼容性问题的场景。
启用 TUN 前，建议先关闭其他 VPN、网络加速器和重复的虚拟网卡软件，避免路由冲突。在 Clash Verge Rev 中开启 TUN 后，按系统提示授予权限，并保留规则模式，不要直接切换全局模式。测试完成后，可以分别检查浏览器、Zotero、Overleaf 和 Git 是否都能连接。
DNS 配置的基本原则
科研网站经常依赖多个跳转域名和内容分发域名。DNS 解析异常时，表现可能是主站偶尔能打开、登录页面循环跳转，或者 PDF 链接解析到不可用地址。Mihomo 配置可以参考以下思路，但请结合本地网络和客户端版本调整：
如果某个校园服务使用固定内网域名或私有地址，应加入 fake-ip-filter，让它继续采用真实解析方式。例如校园认证、打印机、实验室服务器和本地 NAS 都可能不适合 fake-IP。修改 DNS 后要清理系统 DNS 缓存，并重新启动浏览器或 Zotero，避免旧解析结果继续影响测试。
按照现象定位问题
- Scholar 能打开但搜索结果为空：检查节点出口、浏览器扩展和 Cookie 状态，避免频繁刷新或同时发送大量自动化请求。
- arXiv 页面正常但 PDF 下载失败：查看下载链接实际域名，确认它没有被兜底规则分配到直连，并测试更稳定的节点。
- IEEE Xplore 要求反复登录：固定节点和浏览器会话，避免在多个国家或地区之间快速切换出口；如果使用校园单点登录，应确认机构认证流程允许当前连接方式。
- Zotero 同步卡住：查看连接日志，区分是官方同步、附件存储还是 WebDAV 出错，并分别测试策略组。
- Overleaf 编译失败：确认项目中的外部图片、字体或 Git 资源是否可访问，同时检查 TUN 模式是否造成重复代理。
- 国内网站变慢：检查规则顺序，确保
GEOIP,CN,DIRECT、局域网地址和常用国内域名没有被科研策略组提前接管。
维护建议
每次更新订阅后都要重新确认策略组名称是否变化。可以备份自己的规则片段，并记录“节点、时间、服务、错误现象”四项信息，这比反复点击测速更容易找到真正原因。
最后，科研配置的重点不是规则越多越好，而是让每条规则都可解释、可验证、可回退。建议先从 Scholar、Zotero 和 Overleaf 三类核心服务开始，确认稳定后再逐步加入出版社、代码仓库和数据平台。遇到服务异常时，优先查看 Clash 日志、DNS 结果和节点状态，必要时暂时恢复直连或使用机构提供的官方访问方式。