为什么科研工作流需要单独设计 Clash 分流

科研人员使用网络工具时，通常不是简单地把所有流量切换到同一个代理出口。一天之内，你可能先用浏览器检索 Google Scholar、Semantic Scholar、PubMed 或出版社页面，再打开 Zotero 同步附件，随后在 Overleaf 与合作者编译论文，最后还要访问学校内网、国内期刊平台、实验室 NAS、企业邮箱和在线会议服务。不同服务对延迟、地区、登录状态和 IP 稳定性的要求并不相同。如果直接使用全局代理，学术检索也许变快了，但国内办公系统可能加载异常；如果完全直连，Zotero WebDAV、Overleaf 或海外出版社页面又可能出现超时。

因此，比较适合研究者的方案是按域名和应用场景进行规则分流：国内高校、办公和生活服务保持直连；需要稳定访问的海外学术平台进入一个固定的学术策略组；Zotero 同步相关域名单独观察；Overleaf 的网页、编译服务和 Git 连接则根据日志逐步补齐。这样做的重点不是堆积一份看似完整的域名清单，而是让每一条规则都能解释、能验证、能在服务变化后快速维护。

先把服务分成四类，再决定代理策略

在 Clash 中写规则前，建议先列一张自己的科研服务清单。不要看到一个海外域名就全部加入代理，也不要把所有带有 google 或 cloud 字样的主机都塞进同一个策略组。相同厂商下的不同服务，可能分别承担登录、静态资源、API、文件存储和统计功能，实际连接目标需要以 Clash 的连接日志为准。

• 文献检索与科研信息服务：包括 Google Scholar、Semantic Scholar、PubMed、Crossref、OpenAlex 以及出版社的检索和元数据页面。这类服务通常以 HTTPS 为主，对 DNS 解析和页面资源加载比较敏感，适合进入“学术检索”策略组。
• 文献管理与同步：Zotero 的帐号登录、数据同步、附件同步和 WebDAV 可能不是同一组域名。Zotero 数据同步与附件同步也可能使用不同的存储后端，因此不能只根据 Zotero 主站是否能打开来判断同步链路已经正常。
• 论文写作与协作：Overleaf 网页编辑器、项目编译、图片和字体资源、Git 同步以及邀请链接可能对应不同主机。浏览器能打开 Overleaf，不代表终端里的 Git 或编译相关请求一定走了正确的链路。
• 本地与国内服务：学校门户、校园 VPN、图书馆认证、国内期刊平台、企业 IM、网银、外卖和视频服务通常应保持直连。对这些域名强制代理，可能引入验证码、登录失效或访问速度下降。

策略组不宜一开始就拆得过细。对大多数个人研究者，可以先准备“学术平台”“Zotero 同步”“Overleaf 协作”和“直连”四个逻辑组。前两个组可以先共用一个可靠节点，等日志显示某一服务需要不同地区或不同稳定性时，再进一步拆分。尤其是 Zotero 附件同步，持续传输时间较长，最好不要使用会频繁切换节点的测速组。

Clash 规则怎么写：从稳定的域名后缀开始

规则顺序比规则数量更重要。Clash 通常按照从上到下的顺序匹配，越具体的规则越应该放在前面，兜底规则放在后面。科研场景中，建议先用明确的 DOMAIN 或 DOMAIN-SUFFIX，不要一开始就使用过于宽泛的关键词匹配。例如，DOMAIN-SUFFIX,overleaf.com,Overleaf 比把所有含有 over 的域名送入代理更容易解释，也不容易误伤无关服务。

下面是一份用于说明结构的片段。策略组名称必须替换成你自己的配置名称，域名也应根据实际连接日志和服务官方文档调整。不要把示例当作永远不变的完整清单，平台可能会增加 CDN、认证或静态资源域名。

proxy-groups:
  - name: Academic
    type: select
    proxies:
      - "Research-Node"
      - "DIRECT"

  - name: Zotero
    type: select
    proxies:
      - "Research-Node"
      - "Academic"

  - name: Overleaf
    type: select
    proxies:
      - "Research-Node"
      - "Academic"

rules:
  - DOMAIN-SUFFIX:scholar.google.com
    rule: Academic
  - DOMAIN-SUFFIX:semanticscholar.org
    rule: Academic
  - DOMAIN-SUFFIX:pubmed.ncbi.nlm.nih.gov
    rule: Academic
  - DOMAIN-SUFFIX:zotero.org
    rule: Zotero
  - DOMAIN-SUFFIX:overleaf.com
    rule: Overleaf
  - DOMAIN-SUFFIX:edu.cn
    rule: DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Academic

不同客户端和内核的 YAML 写法可能略有差异，部分 Mihomo 配置使用标准的逗号分隔规则格式，例如 DOMAIN-SUFFIX,overleaf.com,Overleaf，而不是上面为了说明字段含义而展开的对象形式。导入前应以当前客户端生成的配置格式为准。最稳妥的做法是先在客户端中创建策略组，再复制现有规则的语法，不要直接把不确定的格式覆盖到正在使用的订阅文件里。

关于 Google Scholar 等服务，还要注意一个常见误区：只代理主页面不一定足够。搜索结果中的跳转可能指向出版社、机构仓储、DOI 服务或独立的 PDF 存储域名。若页面能加载但点击论文后超时，先看连接日志中的真实目标主机，再决定是否增加规则。对 DOI、Crossref 和 OpenAlex 等元数据服务，也不建议简单归入“全部 Google”规则，否则后续排查会变得困难。

动手配置：用日志完成一次科研工作流验证

下面的操作顺序适用于 Clash Verge Rev、Mihomo Party 等支持规则查看和连接日志的客户端。首次配置时，不建议同时打开 TUN、修改 DNS、切换多组节点。一次只改一个变量，才能知道结果来自哪一项设置。

1. 备份当前配置：复制正在使用的配置或记录订阅名称、策略组和 DNS 设置。确认备份文件不包含公开分享的订阅链接，必要时将 Token 打码。
2. 准备稳定策略组：创建或选定一个“学术平台”策略组，先手动选择一个延迟尚可、连续使用稳定的节点，不要在第一次测试时使用会自动切换的 url-test。
3. 从最小规则集开始：先加入 Zotero 主域名、Overleaf 主域名和一个实际使用的学术检索域名。保存配置并确认客户端能成功解析配置，没有出现策略组不存在或 YAML 缩进错误。
4. 测试浏览器检索：打开无痕窗口访问目标平台，执行一次关键词搜索，再打开一个论文详情页。回到 Clash 的连接列表，记录真实请求域名、命中的规则和最终策略组。
5. 测试 Zotero 登录与同步：在 Zotero 中先执行数据同步，确认帐号状态更新；再同步一个小型附件或新建测试条目。不要直接用大量 PDF 做首次测试，以免失败重试造成重复上传。
6. 测试 Overleaf：先打开项目并编辑一处无关紧要的文字，再执行一次小型编译。若使用 Git，从终端单独执行拉取或推送，并分别检查浏览器与终端的连接是否出现在日志中。
7. 补充漏网域名：只把日志中反复出现、且确实属于目标服务的域名加入规则。每次增加一条或一组规则后重新测试，不要根据陌生域名名称凭感觉大范围放行。
8. 验证国内服务：访问学校门户、图书馆认证或常用办公服务，确认它们仍命中 DIRECT 或预期的国内策略。若校园 VPN 需要特定网段，应优先遵循学校提供的客户端和路由说明。

如果浏览器测试成功而 Zotero 失败，首先不要立即开启全局模式。先区分是数据同步失败、附件同步失败，还是帐号登录失败。数据同步与附件同步可能使用不同的云端存储链路；附件失败时可以在连接日志中观察大文件传输对应的主机，并检查是否存在节点切换、连接重置或超时。若 Zotero 使用 WebDAV，还要确认 WebDAV 服务商的域名是否被单独规则覆盖。

Overleaf 也应拆成多个层次验证。网页编辑器正常，只能说明浏览器访问主站基本可用；编译失败可能来自资源下载、字体、图片、编译队列或项目本身的 LaTeX 错误。Git 同步则由终端进程发起，很多终端程序不会自动继承浏览器扩展的代理设置。若没有开启 TUN，可以在同一终端里配置与 Clash 混合端口对应的 HTTP_PROXY 和 HTTPS_PROXY，并用连接日志确认请求确实进入代理。

DNS、TUN 与常见故障的排查顺序

学术平台访问异常时，DNS 经常被误认为唯一原因。实际上，解析成功不代表 TLS 连接、规则匹配和节点出口都正常；反过来，页面打不开也可能只是某个脚本或验证码域名漏配。建议先看 Clash 连接日志，再判断是否需要修改 DNS。日志中如果显示请求命中了 DIRECT，优先修正规则；如果已经命中正确策略但连接超时，再比较节点、DNS 和网络环境。

• 页面打开但搜索按钮无响应：检查脚本、验证码或 API 请求是否被直连规则抢先匹配。用浏览器开发者工具或 Clash 连接记录找出失败的主机，不要只检查地址栏里的主域名。
• Zotero 一直显示同步中：分别测试数据和附件同步，检查时间是否准确、帐号是否需要重新授权，以及节点是否在同步过程中发生切换。大附件失败不代表 Zotero 全部网络都失败。
• Overleaf 网页能开但编译失败：查看项目编译日志，区分网络资源下载错误与 LaTeX 语法错误。如果只有某些图片或字体加载失败，记录对应 CDN 域名后再补规则。
• 终端 Git 不走代理：系统代理只对遵循系统设置的程序有效，终端工具可能需要环境变量、Git 配置或 TUN 接管。确认本机混合端口、协议类型和 NO_PROXY 设置没有冲突。
• 开启 TUN 后校园网或内网异常：先关闭 TUN 恢复系统网络，再检查局域网、学校网段、网关和 DNS 劫持设置。TUN 不是越早开启越好，只有系统代理覆盖不到的应用确实需要接管时再使用。

DNS 配置方面，研究者常见的需求是让国内域名继续使用合适的解析路径，同时让海外学术服务避免被错误污染。不同网络环境对 fake-ip、redir-host、nameserver-policy 和 fallback 的表现差异较大，不能照搬他人的完整 DNS 段落。修改前应保存原配置，并通过域名解析结果、连接日志和实际访问三者交叉验证。若只改 DNS 而不检查规则，最终可能得到“解析看起来正常、请求仍然走错出口”的假修复。

让规则适合长期论文项目，而不是只解决一次访问

科研项目通常会持续数月甚至数年，配置的可维护性比某次测速结果更重要。首先，尽量使用清晰的策略组名称，例如“Academic”“Zotero”“Overleaf”，不要把多个用途都塞进一个名为“Proxy”的组里。其次，为固定研究项目保留一份本地说明，记录哪些域名用于检索、哪些域名用于同步、哪些规则必须直连。团队协作时，也不要把个人订阅链接、节点名称和帐号信息直接提交到 Git 仓库。

其次，给长期连接预留稳定出口。Zotero 附件同步、Overleaf Git 操作和远程协作都不适合在传输中频繁更换节点。自动测速可以用于普通网页浏览，但在连续同步前最好手动确认当前节点。若学校、出版社或协作平台对登录地区较敏感，短时间内频繁改变出口也可能触发额外验证。

最后，定期清理过期规则。平台改版后，旧的 CDN 域名可能不再使用；过多宽泛规则会让配置越来越难读，也可能把不需要代理的服务误送到海外节点。建议以“实际日志出现过、确实属于目标服务、经过一次成功验证”为加入条件，以“连续一段时间未使用或已确认失效”为删除条件。这样既能减少配置复杂度，也能让下一位接手项目的研究者看懂这套分流逻辑。

相比之下，许多同类代理工具要么只提供全局开关和简单 PAC，要么规则编辑、连接日志与订阅覆写分散在不同入口，遇到 Zotero 附件同步或 Overleaf 终端 Git 这类跨应用场景时，往往需要自己拼凑文档，兼容性和排障体验也不够稳定。Clash 官网 更适合把科研工作流拆成可验证的步骤：通过清晰的策略组、规则分流、日志观察和跨平台配置思路，帮助你在保留国内办公直连的同时管理学术平台流量；如果你正准备为 Zotero、Overleaf 和文献检索建立一套可维护的 Clash 环境，不妨免费下载 Clash 官网，按本文的最小规则集先跑通，再逐步扩展到自己的研究服务。