科研人员Clash配置指南：Scholar、Zotero与Overleaf工作流

科研工作流中的网络边界：检索、同步与写作并不相同

科研人员使用代理时，最容易遇到的误区是把「能打开网页」当成「整套科研工作流已经连通」。实际上，Google Scholar、arXiv、IEEE Xplore、Zotero 与 Overleaf承担的网络职责并不一样：Scholar 主要用于检索与跳转，arXiv 还涉及论文 PDF 和源文件下载，IEEE Xplore 可能在机构认证、摘要页和全文资源之间多次重定向，Zotero 同时处理网页抓取、附件下载、WebDAV 或云端同步，Overleaf 则依赖浏览器前端、项目接口、编译服务与 Git 同步。只给浏览器设置系统代理，不能保证 Zotero 后台进程、Git 客户端或 PDF 下载器使用同一条路径。

这也是为什么不少研究者会看到一种具有迷惑性的现象：Google Scholar 首页可以加载，点击论文标题后却卡在出版社页面；Zotero 能保存网页题录，却下载不了附件；Overleaf 编辑器打开正常，编译时却长时间停在队列中。此时不应立即把所有流量切换到全局代理，而要先区分域名解析、网页访问、文件下载、账户认证和长连接编译这几类请求，再决定哪些目的地需要代理，哪些目的地应保持直连。

在 Clash 中，推荐采用「规则模式 + 明确策略组」的基础结构。国内常用服务、学校内网、实验室服务器和本地 NAS 通常放入直连策略；海外学术检索、开放论文仓库、文献同步服务和在线写作平台则按照实际连接日志逐步加入科研专用策略组。这样做的价值不只是提高成功率，也方便你在出现故障时回答三个问题：请求去了哪个主机、命中了哪条规则、最终使用了哪个节点。

Google Scholar、arXiv 与 IEEE Xplore 的分流设计

Google Scholar的访问链路通常不止一个主域。检索页面、登录状态、引用导出、跳转到出版商以及验证码或静态资源，可能由不同的主机提供。实际配置时可以先将 Scholar 相关域名归入 RESEARCH_PROXY，再观察点击搜索结果后的目标站点是否也需要代理。尤其要注意，Scholar 本身只是索引入口，论文全文常常位于大学机构库、出版社平台或开放存档，不能因为 Scholar 页面能够打开，就假定全文来源也会自动走正确路径。

arXiv更适合按「网页、论文文件、辅助资源」三个层次观察。摘要页可能可以正常访问，但 PDF 下载会连接不同的静态资源域；当你批量下载或使用 Zotero 保存条目时，短时间内还会产生多个并发连接。若只为首页写了精确的 DOMAIN 规则，文件请求可能落入默认直连。建议先在日志中下载一篇摘要页和一篇 PDF，确认真实域名后，再使用较稳定的 DOMAIN-SUFFIX 或经过维护的 Rule Provider。

IEEE Xplore及其他出版社平台则要特别留意机构认证。通过校园网络、VPN、图书馆代理或单点登录访问时，认证域、内容域与下载域可能分属不同体系。如果你在校外使用 Clash，不能简单地把所有出版社域名都加入代理后就结束排查：有些机构访问入口要求固定的学校出口，有些资源需要先完成浏览器 Cookie 或 SAML 跳转。代理只能改善网络可达性，不能绕过付费权限、机构许可或服务条款。

一个便于维护的规则骨架可以如下所示。示例中的策略组名称只是意图名称，节点列表和规则集应按你的订阅与所在网络环境替换；规则顺序仍然重要，科研域名规则应放在兜底规则之前。

Illustrative Clash rules

proxy-groups:
  - name: RESEARCH_PROXY
    type: select
    proxies:
      - PROXY
      - DIRECT

rules:
  - DOMAIN-SUFFIX,scholar.google.com,RESEARCH_PROXY
  - DOMAIN-SUFFIX,arxiv.org,RESEARCH_PROXY
  - DOMAIN-SUFFIX,ieeexplore.ieee.org,RESEARCH_PROXY
  - DOMAIN-SUFFIX,overleaf.com,RESEARCH_PROXY
  - DOMAIN-SUFFIX,zotero.org,RESEARCH_PROXY
  - MATCH,DIRECT

这段配置不代表所有相关请求都只会出现这些域名。更稳妥的做法是先保留一个可手动切换的 RESEARCH_PROXY，测试一项任务后再决定是否改成自动选择。若某个节点能打开检索页，却无法稳定下载大文件，可以为下载任务单独建立 RESEARCH_DOWNLOAD；如果多个策略组使用同一节点池，也应通过清晰的命名区分「网页检索」和「长时间下载」，避免日后看到连接日志时无法判断意图。

Zotero：题录抓取、附件下载与同步要分开验证

Zotero的网络行为经常被低估。浏览器中的 Zotero Connector 负责识别网页元数据，并把题录发送给桌面端；桌面端可能继续请求 DOI、出版社页面或开放获取服务来寻找 PDF；附件同步又可能走 Zotero 云服务、WebDAV 服务器或机构提供的存储端点。三个阶段任意一个失败，用户都可能笼统地说「Zotero 不能同步」，但对应的解决方法完全不同。

当网页上点击浏览器扩展后只能保存一个普通网页条目，首先检查页面本身是否提供结构化元数据，以及 Connector 是否能访问页面中的题录接口。此时不要马上修改 DNS 或打开 TUN。可以先手动复制 DOI、ISBN 或论文标题，在 Zotero 中用「通过标识符添加条目」测试。如果标识符识别成功而网页保存失败，问题更接近浏览器扩展、页面结构或出版商限制；如果两者都失败，再检查 Clash 日志中是否出现了目标主机的超时、TLS 错误或错误的直连规则。

PDF 附件下载是另一条链路。出版社常通过重定向、对象存储或 CDN 提供文件，下载 URL 的主机名未必包含出版社名称。推荐在 Zotero 开始下载时立即观察连接日志，并记录「开始下载」到「下载完成」期间出现的域名。若网页已打开但 PDF 始终为零字节，可以暂时把相关下载域加入科研策略组；如果同一个域承载大量无关资源，则优先采用更精确的 DOMAIN 规则，避免把整个 CDN 误送到代理。

同步问题还要区分数据同步与附件同步。题录、标签和笔记通常属于数据库同步，附件则可能受存储方案、容量和 WebDAV 配置影响。建议先新建一条无附件的测试条目，观察多设备能否同步；再上传一个体积较小的 PDF，确认附件通道；最后再测试大文件和批量同步。若只在校园网或单位 VPN 环境中失败，要检查 Clash 的 TUN、系统路由和单位 VPN 是否同时接管同一目的地，双重默认路由经常会造成同步反复重试。

重要：Zotero 同步异常不一定需要更换节点。先看账户认证是否成功、题录是否能同步、单个附件是否能上传，再判断是规则、DNS、存储服务还是账户配额问题。把四类问题混在一起，只会让排障结果失去可重复性。

Overleaf：DNS、浏览器会话与编译连接

Overleaf的使用体验通常包含登录、项目列表、编辑器实时保存、资源加载、编译请求和 PDF 预览等多个环节。项目页面能打开，并不代表实时保存与编译服务一定正常。编辑器中的请求可能保持较长时间，编译完成后还要把生成的 PDF、日志和错误信息返回浏览器。如果代理节点频繁更换、连接空闲时被回收，表面上就会表现为「编辑器偶尔断开」或「编译一直排队」。

因此，Overleaf 不宜使用会在每个请求之间频繁切换出口的策略。可以为 overleaf.com 及日志中确认的相关域名建立稳定的策略组，并优先选择延迟平稳、长连接表现良好的节点。url-test适合筛选可用成员，但测速地址的结果不能完全代表 Overleaf 编译体验；如果你发现同一项目在某节点上连续编译成功，就可以在科研策略组中暂时固定该节点，等工作结束后再恢复自动选择。

DNS 方面，重点不是盲目追求最快解析，而是让解析结果与出站路径保持一致。启用 Clash 的增强模式或 TUN 后，要确认 DNS 请求没有被系统、浏览器安全 DNS、单位 VPN 和 Clash 同时处理。多套解析器并行时，可能出现浏览器拿到一个地址、Clash 按另一个地址建立连接的情况，最终在日志中看到反复重试。遇到这种问题，可以暂时关闭浏览器的独立安全 DNS，使用 Clash 统一解析，再用连接日志和实际访问结果对照。

如果 Overleaf 首页加载正常而编译失败，先在浏览器开发者工具或 Clash 日志中观察编译按钮点击后的新连接。若请求根本没有发出，可能是页面脚本、浏览器扩展或缓存问题；若请求发出后超时，则继续检查代理节点、长连接和 DNS；若编译完成但 PDF 预览失败，则要单独关注文件返回和静态资源。每次只改一个变量，并记录修改前后的结果，才能避免把偶然恢复误判为真正修复。

DNS、规则顺序与可重复的排障方法

科研代理配置最值得投入时间的部分，不是写出最长的规则列表，而是建立一套可重复的验证流程。建议先备份当前配置，再确认 Clash 核心处于运行状态、模式为 Rule、系统代理或 TUN 的入口确实生效。随后关闭不必要的浏览器扩展和其他代理软件，避免多个进程争用端口。测试时准备五个最小任务：打开 Scholar 搜索页、下载一篇 arXiv PDF、保存一条 Zotero 题录、同步一个小附件、在 Overleaf 编译一个简单项目。

每完成一个任务，就在连接日志中记录域名、规则、策略组、节点和结果。可以使用下面的表格作为排障记录模板：

规则顺序方面，应先处理明确的科研服务域名，再处理更宽泛的分类规则，最后才使用 MATCH 兜底。若配置中同时存在多个 Rule Provider，要确认它们的加载顺序和更新状态；旧规则集可能把某个域名提前判定为直连，导致你后来新增的规则永远无法命中。排查时可以暂时把特定域名放在本地规则最前面，验证成功后再将长期维护内容迁移到 Rule Provider。

DNS 故障还可能表现为「偶尔能用」。这是因为不同时间解析到的地址、缓存过期时间和节点出口并不一致。可先清理本地 DNS 缓存，重启 Clash 核心，再在同一网络环境下重复测试；不要在切换 Wi-Fi、移动热点、单位 VPN 和节点的同时修改规则。若只有校园网出现问题，还应询问网络管理员是否存在透明代理、IPv6 出口限制或必须使用的认证门户，这些因素不是 Clash 单独调整几行 YAML 就能解决的。

最后，保存一份经过验证的配置版本，并在文件名或 Git 提交中记录日期、节点策略和测试结果。今后订阅更新、核心升级或更换网络后，只需重新执行五个最小任务，就能快速判断变化来自规则、DNS、客户端还是上游服务。相比「遇到打不开就切全局」的临时做法，这种方法更适合需要长期维护文献库、持续写论文和多人协作的科研环境。

与只提供浏览器开关的简单代理工具相比，Clash V.CORE 能把 Scholar 检索、Zotero 同步和 Overleaf 编译分别纳入可观察的规则与策略组，既避免全局代理带来的国内服务绕路，也减少传统系统代理对后台应用覆盖不足的问题；当你需要 TUN、稳定 DNS、连接日志和可维护的 Rule Provider 时，配置一次即可持续复用。若你希望把这套科研工作流落地到自己的设备，不妨前往下载 Clash V.CORE，再按照本文的最小测试流程逐项验证，而不是直接把所有流量交给一个无法解释的全局模式。

配置维护：订阅更新、节点切换与隐私边界

科研环境中的代理配置往往会使用数月甚至数年，因此维护策略和初次配置同样重要。订阅更新后，节点名称、策略组结构和规则集可能发生变化，原本手动写入的组名也可能被远程配置覆盖。建议将「订阅提供的基础配置」与「个人科研覆写」分开管理，并在每次更新后检查 RESEARCH_PROXY 是否仍然存在、默认节点是否可用、规则是否仍按预期命中。若客户端支持 Profile 覆写或补丁机制，优先使用该方式，而不是直接编辑每次都会被替换的订阅文件。

节点切换也应有明确标准。不要只看延迟数字，还要观察 Scholar 搜索是否稳定、PDF 下载是否持续、Zotero 附件是否能完成上传、Overleaf 编译是否可以连续成功。对于长时间写作，稳定性通常比一次测速中的最低延迟更重要。可以为科研策略组保留两个或三个经过验证的节点，并通过手动选择或健康检查进行切换；如果不同节点的出口地区会影响机构认证，应在测试记录中标注地区与认证结果。

还要注意论文、项目源文件和同步凭据的隐私边界。代理日志可能记录域名、连接时间和流量大小，但不应把 API 密钥、Zotero 密码或项目内容复制到公开配置、截图和调试日志中。共享配置时删除订阅链接中的个人令牌，导出连接日志前检查是否包含完整 URL 或认证信息。Clash 负责路由与连接管理，不能替代端到端加密、账户多因素认证、机构安全政策和论文数据管理要求。