科研人员用 Clash 连通学术平台与 Zotero 的工作流指南

为什么科研工作流得单独设计 Clash 分流 一文看懂

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

科研人员运用网络工具时，一般不是容易地把全部流量切换到同一个代理出口。一天之内，你也许先用浏览器检索 Google Scholar、Semantic Scholar、PubMed 或出版社页面，再开启 Zotero 同步附件，随后在 Overleaf 与合作者编译论文，最后还要连通学校内网、国内期刊平台、实验室 NAS、企业邮箱和在线会议服务。

不同服务对时延、地区、登录状态和 IP 稳健性的要求并不相同。如果干脆运用全局代理，学术检索也许变快了，但国内办公系统也许加载异常；如果完全直连，Zotero WebDAV、Overleaf 或海外出版社页面又也许出现超时。

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

在 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 规则怎么写：从稳健的域名后缀开始 逐条拆解

若页面能加载但点击论文后超时，先看连接日志中的真实目标主机，再决定是否增加规则。对 DOI、Crossref 和 OpenAlex 等元数据服务，也不推荐容易归入“全部 Google”规则，否则后续排查会变得困难。

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

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

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

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

关于 Google Scholar 等服务，还要留意一个高频误区：只代理主页面不一定充分。搜索结果中的跳转也许指向出版社、机构仓储、DOI 服务或独立的 PDF 存储域名。

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

Git 同步则由终端进程发起，很多终端程序不会无人值守继承浏览器扩展的代理设置。若没有开启 TUN，能够在同一终端里配置与 Clash 混合端口对应的 HTTP_PROXY 和 HTTPS_PROXY，并用连接日志确认请求确实进入代理。

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

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

换个角度：如果浏览器测试成功而 Zotero 不成功，第一气不要立即开启全局模式。先区分是数据同步不成功、附件同步不成功，还是帐号登录不成功。数据同步与附件同步也许运用不同的云端存储链路；

附件不成功时能够在连接日志中观察大文件传输对应的主机，并核对是否存在节点切换、连接重置或超时。若 Zotero 运用 WebDAV，还要确认 WebDAV 服务商的域名是否被单独规则覆盖。

Overleaf 也应拆成多个层次验证。网页编辑器正常，只能说明浏览器连通主站基本可用；编译不成功也许来自资源下载、字体、图片、编译队列或项目本身的 LaTeX 失误。

DNS、TUN 与高频故障的排查顺序 一文看懂

修改前应保存原配置，并通过域名解析结果、连接日志和实际连通三者交叉验证。若只改 DNS 而不核对规则，最终也许得到“解析看起来正常、请求仍然走错出口”的假修复。

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

具体来说：学术平台连通异常时，DNS 经常被误认为唯一缘由。事实上，解析成功不代表 TLS 连接、规则匹配和节点出口都正常；反过来，页面打不开也也许只是某个脚本或验证码域名漏配。推荐先看 Clash 连接日志，再判断是否得修改 DNS。日志中如果显示请求命中了 DIRECT，首位修正规则；如果已经命中无误策略但连接超时，再相当节点、DNS 和网络环境。

DNS 配置方面，研究者高频的需求是让国内域名继续运用合适的解析路径，同时让海外学术服务避免被失误污染。不同网络环境对 fake-ip、redir-host、nameserver-policy 和 fallback 的表现差异较大，不能照搬他人的齐全 DNS 段落。

让规则适合长期论文项目，而不是只处理一次连通 核心要点

Clash 更适合把科研工作流拆成可验证的流程：通过明白的策略组、规则分流、日志观察和跨平台配置思路，帮助你在保留国内办公直连的同时管理学术平台流量；如果你正准备为 Zotero、Overleaf 和文献检索建立一套可维护的 Clash 环境，不妨免费下载 Clash，按这篇文章的最小规则集先跑通，再逐步扩展到亲手的研究服务。

科研项目通常会持续数月甚至数年，配置的可维护性比某次测速结果更关键。第一气，尽量运用明白的策略组名称，比如“Academic”“Zotero”“Overleaf”，不要把多个用途都塞进一个名为“Proxy”的组里。

顺带一提：第二点，为固定研究项目保留一份本地说明，记录哪些域名用于检索、哪些域名用于同步、哪些规则必须直连。团队协作时，也不要把个人订阅链接、节点名称和帐号信息干脆提交到 Git 仓库。

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

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

先看这一点：相比之下，众多同类代理工具要么只提供全局开关和容易 PAC，要么规则编辑、连接日志与订阅覆写分散在不同入口，遇到 Zotero 附件同步或 Overleaf 终端 Git 这类跨应用状态时，一般得亲手拼凑文档，兼容性和排障运用感受也不够稳健。