科研工作中的网络需求往往不是简单的「全部代理」或「全部直连」。检索论文时需要稳定访问 Google Scholar、PubMed、Semantic Scholar、arXiv 等学术网站;使用 Zotero 时又涉及 WebDAV、云端同步和附件下载;在 Overleaf 协作时,还要保持项目页面、Git 仓库、图片资源与编译服务的连接稳定。不同服务的网络路径和访问特征并不相同,如果只使用全局代理,可能导致国内数据库变慢、校园网资源无法访问,甚至让 Zotero 同步和 Overleaf 编译出现间歇性失败。
本文以研究者的日常工作流为主线,讲解如何使用 Clash 或 Mihomo 构建一套更稳妥的科研网络配置。重点不是堆砌规则,而是把学术网站分流、Zotero 同步、Overleaf 协作、终端代理和故障排查拆开处理,让每一类请求都走更合适的路径。
科研工作流中的网络需求
一台用于科研的电脑通常同时运行浏览器、Zotero、VS Code、Git、TeX 编译环境以及各种同步工具。这些程序的联网方式并不一致:浏览器遵循系统代理或扩展设置,Zotero 可能使用操作系统代理,Git 和命令行工具则常常需要单独设置环境变量。Clash 只负责接收已经进入代理内核的流量,因此第一步是明确每项任务的访问对象和代理需求。
| 工作环节 | 常见服务 | 建议路径 | 配置重点 |
|---|---|---|---|
| 文献检索 | Google Scholar、PubMed、arXiv、出版社网站 | 按域名代理 | 优先保证搜索、摘要和 PDF 下载连续可用 |
| 文献管理 | Zotero API、WebDAV、云端附件 | 按服务商决定 | 同步域名必须稳定,避免频繁超时和重复重试 |
| 在线写作 | Overleaf、GitHub、CI 服务 | 代理或主备策略 | 保证项目加载、编译日志和资源文件正常访问 |
| 校园资源 | 校内图书馆、CNKI、机构 VPN、实验室服务器 | 直连或校园网专用路径 | 不要让代理规则覆盖内网地址 |
| 命令行工具 | Git、pip、npm、Docker、TeX Live | 显式 HTTP 代理 | 分别检查环境变量与程序自身代理设置 |
建议先建立「按用途分组」的思路,而不是按国家或地区简单划分。例如,学术检索可以使用一个稳定的代理组,GitHub 和 Overleaf 使用另一个代理组,国内高校资源则明确直连。这样做的好处是:当某个节点对论文网站速度较慢时,可以单独替换学术策略组,而不会影响其他应用。
学术网站分流设计
学术网站通常包含多个不同用途的域名。主站负责页面展示,身份认证可能跳转到独立域名,PDF 文件则可能来自对象存储或 CDN。如果只代理主页域名,页面能够打开,但登录、文献下载或全文跳转仍可能失败。因此配置时要考虑「入口域名、认证域名、内容域名」三类对象。
在 Mihomo 配置中,可以使用 DOMAIN-SUFFIX 匹配主域名及其子域名,用 DOMAIN 匹配单个精确域名。对于规则数量较少的个人配置,直接写在 rules 中便于理解;当规则逐渐增加后,再迁移到 Rule Provider。
proxy-groups: - name: 科研访问 type: select proxies: - 自动选择 - 香港节点 - 日本节点 - DIRECT rules: # 文献检索与预印本服务 - DOMAIN-SUFFIX,scholar.google.com,科研访问 - DOMAIN-SUFFIX,googleusercontent.com,科研访问 - DOMAIN-SUFFIX,arxiv.org,科研访问 - DOMAIN-SUFFIX,semanticscholar.org,科研访问 - DOMAIN-SUFFIX,sciencedirect.com,科研访问 - DOMAIN-SUFFIX,springer.com,科研访问 # 国内学术资源与本地网络 - DOMAIN-SUFFIX,cnki.net,DIRECT - DOMAIN-SUFFIX,edu.cn,DIRECT - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve # 其他请求放到默认策略组 - MATCH,默认代理
上面的域名仅用于说明规则结构,并不能保证覆盖某个服务的全部请求。实际使用时,应根据连接日志补充认证、静态资源和下载域名。规则顺序也非常重要:Clash 从上到下匹配,越具体的规则越应该放在前面,兜底的 MATCH 必须放在最后。
如果你的网络环境需要登录校园图书馆或机构 VPN,应优先确认学校的访问要求。有些机构服务依赖特定出口 IP,强行通过代理节点访问可能触发二次验证或拒绝连接。对于校内域名、校园网网段和实验室服务器,通常应该设置为直连,并确保 Clash 的系统代理没有破坏本地 DNS 或 VPN 路由。
Zotero 同步与附件访问
Zotero 的数据同步和附件同步是两个容易混淆的部分。数据同步主要涉及文献条目、标签、笔记和集合结构;附件同步则可能使用 Zotero Storage、WebDAV 或其他第三方存储。前者请求量小但对稳定性敏感,后者可能传输较大的 PDF、图片和补充材料,对超时、连接复用和带宽更敏感。
配置 Zotero 代理前,先在 Clash 中观察 Zotero 启动、同步和下载附件时产生的连接。不要只根据浏览器能够打开的域名来推断 Zotero 的全部依赖,因为桌面客户端的请求可能使用不同的 API 地址。若 Zotero 处于「正在同步」状态很久,常见原因包括 DNS 解析失败、代理策略组不可用、WebDAV 地址证书异常,或系统代理只对浏览器生效。
对于使用 WebDAV 的用户,可以把 WebDAV 服务商域名单独加入一个策略组。如果服务商距离较近,直连可能更快;如果服务商位于境外且本地网络访问不稳定,则使用科研代理组通常更可靠。不要为了提高速度而关闭 HTTPS 证书验证,也不要把 WebDAV 用户名和密码直接写入公开分享的配置文件。
proxy-groups: - name: Zotero同步 type: fallback proxies: - 科研访问 - 备用节点 - DIRECT url: https://www.gstatic.com/generate_204 interval: 120 rules: # 根据连接日志替换为实际使用的同步或 WebDAV 域名 - DOMAIN-SUFFIX,zotero.org,Zotero同步 - DOMAIN-SUFFIX,webdav.example.com,Zotero同步
同步测试应该分三步进行:先同步少量条目,确认元数据能够上传;再下载一份小型附件,观察是否能够完整打开;最后再测试较大的 PDF 或压缩包。每一步都要查看 Zotero 的同步日志和 Clash 的连接记录。如果只在大文件传输时失败,可以尝试更换节点、降低并发下载数量,或检查代理服务商对长连接和大流量的限制。
Overleaf、Git 与在线协作
Overleaf 的使用场景包括在线编辑、项目同步、图片上传、PDF 编译和团队协作。编辑器页面打开并不代表全部功能正常,因为编译日志、字体资源、图片文件和项目 API 可能在不同请求中完成。配置时建议将 Overleaf 主域名及其子域名放入同一策略组,避免页面走代理而资源请求直连,造成登录循环、编译超时或资源加载不完整。
如果项目使用 Git 同步,还需要单独处理 GitHub、GitLab 或机构 Git 服务。浏览器中的 Overleaf 请求可以由 Clash 系统代理接管,但终端中的 Git 通常依赖 HTTP_PROXY、HTTPS_PROXY 或 Git 自身的配置。二者并不是一回事。尤其在多人共用电脑或实验室服务器上,不建议把代理地址永久写入全局配置,以免把内网仓库、局域网服务和敏感凭据发送到错误的出口。
http://127.0.0.1:7890 的地址;需要 SOCKS5 时则填写对应的 SOCKS 端口,不能只复制一个端口到所有程序。Overleaf 编译失败不一定是网络问题。若项目在浏览器中可以加载,但编译提示缺少宏包、字体或图片,应先查看编译日志,判断是 LaTeX 错误、项目文件错误还是外部资源访问失败。对于依赖外部 URL 的图片、参考文献或脚本,建议将资源下载到项目中,减少编译过程对临时网络连接的依赖。
动手配置:从连接记录到稳定规则
下面是一套适合个人电脑的操作流程。它不会一次性替你生成完整订阅配置,而是帮助你用最少的规则定位问题,并逐步形成适合自己实验环境的配置。
- 备份当前配置。在 Clash Verge、Clash Verge Rev 或 Mihomo 客户端中复制当前 YAML 文件,另存为带日期的备份文件。修改规则前保留可恢复版本,避免一次错误导致所有应用无法联网。
- 确认代理核心。优先使用支持较新规则和 TUN 能力的 Mihomo 内核。若使用旧版 Clash for Windows 或其他客户端,先确认它支持你配置中使用的字段,不要直接复制包含 Mihomo 专属字段的模板。
- 建立最小策略组。先准备一个科研访问组、一个默认组和一个直连选项。不要一开始加入几十个节点和复杂的自动测速规则,否则出现问题时很难判断是节点、规则还是策略组造成的。
- 逐个测试学术服务。依次打开检索网站、论文全文页面、Zotero 同步和 Overleaf 项目。每测试一个服务,就在连接页面记录实际域名以及命中的策略组。
- 补充精确规则。将确认需要代理的域名写成
DOMAIN-SUFFIX规则,将校园资源和局域网地址写成DIRECT。规则添加后重新加载配置,再观察是否命中预期策略。 - 配置终端代理。在当前终端临时设置代理变量,完成 Git 或包管理器测试后再决定是否持久化。测试结束后记得清理变量,避免在切换网络后产生隐蔽的连接错误。
- 进行故障回归。分别关闭系统代理、切换备用节点、暂停一条规则,然后重复访问同一服务。通过对比结果判断问题来自节点不可用、规则匹配错误,还是应用没有使用 Clash 代理。
# 将端口替换为 Clash 当前的 HTTP 代理端口 export HTTP_PROXY=http://127.0.0.1:7890 export HTTPS_PROXY=http://127.0.0.1:7890 # 测试代理是否生效 curl -I https://github.com # 本次终端会话结束前取消代理变量 unset HTTP_PROXY HTTPS_PROXY
Windows PowerShell 可以使用 $env:HTTP_PROXY 和 $env:HTTPS_PROXY 设置当前会话变量。Git 也可以使用 git config --global http.proxy 配置代理,但全局设置会影响所有仓库,建议只在确实需要时使用,或者为特定仓库设置本地配置。对于实验室服务器,最好通过系统服务、容器网络或跳板机统一管理,不要把个人电脑上的 127.0.0.1 地址直接复制过去。
DNS、TUN 与系统代理的选择
科研应用的兼容性差异很大。浏览器通常能够正确识别系统代理,但某些桌面客户端、命令行程序和基于 Electron 的应用可能只读取环境变量,甚至完全忽略系统代理。此时可以启用 TUN 模式,让操作系统层面的连接通过虚拟网卡交给 Clash 处理。
TUN 模式覆盖范围更广,适合希望统一管理浏览器、Zotero、Git、PDF 阅读器和其他客户端的用户,但它也会影响更多流量,需要更谨慎地处理 DNS 和局域网规则。启用后应确认以下项目:
- Clash 客户端是否获得管理员或系统网络权限;
- 虚拟网卡是否成功创建,系统路由表是否发生预期变化;
- 校园网、打印机、NAS 和实验室服务器是否仍然能够直连;
- DNS 模式是否与当前内核兼容,是否出现本地服务解析失败;
- 关闭 Clash 后,系统网络和原有 VPN 是否能够恢复。
如果主要使用浏览器和 Zotero,系统代理加少量应用级配置通常已经足够;如果还需要覆盖 Git、Docker、终端和不支持代理的桌面软件,再考虑 TUN。不要为了「全局接管」而忽略可维护性。配置越复杂,升级客户端或更换网络环境后越需要重新验证。
常见故障与长期维护
科研网络问题最令人困扰的地方是「偶尔失败」:同一个 PDF 有时能下载,有时超时;Zotero 显示同步完成,但附件实际没有上传;Overleaf 页面正常,编译却长时间停在某一步。排查时应按层次进行,而不是反复切换节点。
| 现象 | 优先检查 | 处理方法 |
|---|---|---|
| 网页完全打不开 | DNS、系统代理、节点连通性 | 查看连接记录,确认请求是否进入 Clash |
| 页面打开但图片或 PDF 失败 | CDN 或附件域名 | 补充实际命中的资源域名,不要只代理主页 |
| Zotero 持续同步 | 同步服务、WebDAV、证书 | 分开测试元数据与附件,检查服务端登录状态 |
| Overleaf 编译超时 | 项目资源、宏包、节点稳定性 | 查看编译日志,优先将外部资源下载进项目 |
| Git 拉取失败 | 终端环境变量或 Git 配置 | 使用 curl 和 git 分别测试,不要假设浏览器代理有效 |
| 校园资源无法访问 | 代理覆盖内网、VPN 路由 | 添加内网 IP 段和校园域名直连规则 |
长期维护时,建议把规则按「学术网站、同步服务、代码平台、校园资源」分组保存,并在注释中记录添加原因和测试日期。节点订阅更新后,先测试一篇论文下载、一次 Zotero 同步和一次 Overleaf 编译,再投入正式工作。若代理服务提供多个出口,使用 fallback 可以提高可用性,使用 url-test 则更适合在延迟差异明显时自动选择节点。
同时要注意隐私和账号安全。Clash 规则只决定流量路径,并不会自动保护 Zotero、Git 或 Overleaf 的登录凭据。不要在共享配置、截图和公开仓库中泄露订阅链接、代理密码、WebDAV 密码或 Clash 控制器密钥。科研数据、未发表论文和实验结果也不应因为网络调试而上传到不受信任的第三方服务。
一套好的科研代理配置,目标不是让所有流量都经过同一个节点,而是让检索、同步、协作和内网访问互不干扰。完成基础分流后,可以根据自己的学校网络、研究方向和常用平台继续细化规则。配置稳定之后,Zotero 的文献整理、Overleaf 的在线编译以及 Git 的版本协作都会更连贯,也能减少在关键写作阶段反复处理网络问题的时间。