科研人员Clash学术访问与Zotero配置实践指南

科研场景的分流目标:检索、同步与写作分开处理

科研人员使用 Clash 时,最容易遇到的问题不是“有没有节点”,而是不同工具对网络的要求并不一样。Google Scholar、arXiv、IEEE Xplore 等论文平台通常需要稳定访问海外站点;学校内网、实验室 NAS、图书馆认证系统又要求保持直连;Zotero 的网页抓取、元数据查询、附件下载和同步服务,还可能分别连接不同的服务器。把所有流量简单切成“全局代理”或“全部直连”,往往会带来新的问题。

更稳妥的思路是按科研工作流拆分出口。论文检索与海外学术平台使用代理策略组,学校门户、校内数据库、局域网设备使用直连,国内软件下载和视频会议根据实际情况单独决定。Zotero 则优先保证浏览器访问、附件下载和同步链路稳定,同时避免把本地数据库、局域网 WebDAV 或校内认证请求错误地送进代理。

本文以 mihomo 内核为例说明配置方法,Clash Verge、Clash Verge Rev、Clash for Windows、ClashX 和 Clash for Android 的菜单名称可能不同,但规则、策略组、DNS 与 TUN 的基本逻辑一致。配置前先确认客户端实际使用的是 mihomo 或 Clash Meta 内核,因为 GEOSITE、RULE-SET、TUN 和部分 DNS 字段并非所有旧版内核都支持。

科研工具流量地图:哪些走代理,哪些保持直连

分流之前,先列出实际使用的应用和服务。浏览器中的论文检索、在线预印本阅读、文献管理器的网页抓取,通常共享浏览器代理;Zotero 桌面端的同步和附件请求则由它自己的网络实现发起,不一定完全遵守系统代理。Overleaf 这类在线写作平台主要依赖浏览器,但项目编译、文件上传和实时协作对连接稳定性要求较高。

表格中的“学术代理组”只是示例名称,可以替换成配置里实际存在的策略组。建议不要在每条规则中直接写某个节点名称,而是统一指向一个策略组。这样节点失效或订阅更新后,只需在策略组中更换出口,不用重新修改大量规则。

先建立独立的学术策略组

如果订阅配置已经提供“节点选择”或“国外代理”策略组,可以直接复用。若需要在自有配置中建立策略组,示例结构如下:

proxy-groups:
  - name: Academic
    type: select
    proxies:
      - Research-Node-1
      - Research-Node-2
      - AUTO
      - DIRECT

  - name: AUTO
    type: url-test
    url: https://www.example.com/generate_204
    interval: 300
    tolerance: 80
    proxies:
      - Research-Node-1
      - Research-Node-2

这里的节点名和测试地址仅为明显的示例,实际使用时应替换为订阅中存在的名称以及服务商建议的测试地址。科研场景不建议把 DIRECT 放在学术组的第一项,否则规则命中后仍可能默认直连;可以保留它作为临时对照选项。

学术访问规则:域名优先,IP 规则兜底

科研平台的分流应尽量采用域名后缀规则,因为一个平台往往包含主站、静态资源、登录服务、文件下载和 API 等多个子域名。只写一个首页地址,会出现首页能打开、PDF 下载失败或登录窗口一直转圈的情况。使用 DOMAIN-SUFFIX 可以覆盖主域名及其子域名,但域名必须根据当前服务实际使用的地址维护,不要盲目复制过时规则。

下面是一个可读性较好的规则框架。示例域名使用文档保留域名,用于展示语法;实际配置时,请把它们替换成你确认过的学术服务域名,并优先使用可靠规则集维护这些条目。

rules:
  - DOMAIN-SUFFIX,school.example,DIRECT
  - DOMAIN-SUFFIX,library.example,DIRECT
  - DOMAIN-SUFFIX,scholar.example,Academic
  - DOMAIN-SUFFIX,preprint.example,Academic
  - DOMAIN-SUFFIX,publisher.example,Academic
  - DOMAIN-SUFFIX,writing.example,Academic
  - DOMAIN-SUFFIX,zotero.example,Academic
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Academic

学校域名放在学术域名之前,是为了避免校内认证入口被后面的宽泛规则误送到代理。局域网网段使用 no-resolve,可以避免 Clash 为了匹配这些 IP 规则而额外解析域名。GEOIP,CN,DIRECT 只适合做兜底,不能代替明确的学术域名规则,因为部分海外服务使用 CDN,IP 归属地可能与服务主体不一致。

使用规则集时检查更新与匹配顺序

mihomo 支持通过 rule-providers 管理远程规则集,适合把学术平台、国内直连和局域网规则分开维护。规则集的便利之处是更新不必反复编辑主配置,但它也带来两个风险:规则来源不可控,以及规则集之间可能存在重叠。导入后应在客户端日志中确认实际命中的规则名称,不能只看配置文件是否加载成功。

rule-providers:
  academic:
    type: http
    behavior: classical
    format: yaml
    url: https://rules.example/academic.yaml
    path: ./rules/academic.yaml
    interval: 86400

rules:
  - RULE-SET,academic,Academic
  - GEOSITE,private,DIRECT
  - GEOIP,PRIVATE,DIRECT,no-resolve
  - MATCH,Academic

如果使用远程规则集,建议先在测试配置中验证,确认格式是 classical、domain 还是 ipcidr,并核对对应的 behavior。不匹配时,客户端可能显示下载成功,但加载阶段仍报格式错误。规则列表最后保留一条 MATCH,并根据自己的默认策略决定未分类流量的出口。

Zotero 配置实践:网页抓取、同步与附件分开验证

Zotero 出问题时,不要只检查“Clash 是否已经连接”。Zotero 的网页抓取通常由浏览器扩展完成,受浏览器代理和证书策略影响;桌面端同步需要访问账号服务;附件同步可能使用 Zotero 自有存储或 WebDAV;本地数据库则完全不需要代理。把这些环节混在一起排查,很容易把“同步失败”误判为节点故障。

1. 先在浏览器中打开一个学术平台,确认页面、登录窗口和 PDF 下载均能完成,再测试浏览器中的 Zotero Connector 抓取。
2. 打开 Clash 日志,执行一次文献抓取,观察是否出现学术平台域名、登录相关域名以及资源文件域名,确认它们命中 Academic 而不是 DIRECT。
3. 在 Zotero 设置的同步页面执行一次手动同步,记录是“账号认证失败”“主库同步失败”还是“附件同步失败”。不同错误对应的网络链路并不相同。
4. 如果使用 WebDAV,单独测试 WebDAV 服务器地址。不要因为网页检索可以访问,就认为 WebDAV 也一定可以连接。
5. 同步成功后再观察附件是否出现云端图标,最后在另一台设备执行下载测试,确认不仅是元数据同步成功。

Zotero 使用代理时的关键边界

如果 Zotero 桌面端没有遵守系统代理,可以在客户端网络设置中填写 Clash 的混合端口,通常地址为 127.0.0.1,端口以当前配置为准。混合端口同时兼容 HTTP 和 SOCKS5 的客户端连接,但不同版本的 Zotero 对代理类型支持方式可能不同,填写后应立即执行同步测试。

使用 TUN 模式时,Zotero 的网络请求可以由虚拟网卡接管,但这不等于所有请求都会自动命中学术规则。若客户端使用 IP 直连、证书固定或独立 DNS,仍可能出现连接超时。此时查看 Clash 日志比反复切换节点更有效:日志没有请求,说明流量没有进入 Clash;日志显示 DIRECT,说明规则需要调整;命中代理但连接重置,则重点检查节点质量、MTU 和远端服务限制。

WebDAV 与附件同步的配置建议

WebDAV 地址是附件同步的独立目标。若 WebDAV 服务位于可直连网络,可以对它使用 DIRECT;若服务在海外,则加入 Academic 或单独建立 Storage 策略组。不要把 WebDAV 地址写成模糊的关键词规则,因为“cloud”“drive”等关键词可能误伤其他云服务。

proxy-groups:
  - name: Storage
    type: select
    proxies:
      - Academic
      - DIRECT

rules:
  - DOMAIN-SUFFIX,webdav.example,Storage
  - DOMAIN-SUFFIX,zotero.example,Academic

附件同步失败还可能来自服务器配额、文件名限制、单文件大小限制或 WebDAV 的认证方式,这些问题与 Clash 无关。判断方法是把当前代理切到稳定节点后再次测试,如果每次都在同一个文件失败,优先检查存储服务日志和配额,不要继续修改 DNS。

DNS 与 TUN:解决加载慢和连接偶发失败

学术平台经常使用 CDN 和多个静态资源域名。DNS 返回的地址如果来自错误区域,可能出现主页打开很快、PDF 下载很慢,或者登录脚本加载失败。仅打开系统代理并不能保证 DNS 经过 Clash,浏览器的安全 DNS 也可能绕过系统设置。需要整机接管时,可在 mihomo 中启用 TUN,并让 DNS 查询统一进入 Clash。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "+.lan"
    - "+.local"
    - "localhost"
  nameserver:
    - https://dns.example/dns-query
  fallback:
    - tls://dns.example:853
  fallback-filter:
    geoip: true
    geoip-code: CN

示例中的 DNS 地址仅用于说明格式,不要直接照抄不存在或不适合当前网络的服务器。fallback 的作用不是简单的“主服务器挂了再启用”,而是让 Clash 对不同结果进行筛选;具体行为取决于内核版本和 fallback-filter 配置。若配置了加密 DNS,还要保证解析器自身的域名能够通过 default-nameserver 引导解析。

fake-ip 适合按域名分流,但部分校园网认证、局域网服务和特殊客户端需要真实地址。遇到学校门户打不开、NAS 访问异常或本地打印机失效时,先把相关域名加入 fake-ip-filter,或者临时切换到 redir-host 对照测试。浏览器若启用了独立的安全 DNS,应暂时关闭该功能或改为遵循系统设置,否则检测结果会与 Clash 日志不一致。

Overleaf 加载不稳定:从浏览器与长连接排查

在线写作平台通常不只是一次网页请求,还包括脚本、字体、项目文件、实时协作和编译状态等长连接资源。若页面能打开但编辑器空白,或者编译结果长时间不刷新,常见原因是部分静态资源被直连、WebSocket 没有走同一策略,以及节点对长连接支持不稳定。

• 先确认浏览器代理。打开浏览器开发者工具的网络面板,刷新页面,检查失败请求的域名是否集中在某一类静态资源或接口。不要只测试首页标题是否出现。
• 检查 WebSocket。在 Clash 日志中观察连接是否持续存在,如果连接刚建立就频繁断开,换一个稳定节点对照,不要立即把所有流量切到全局。
• 关闭冲突的代理扩展。系统代理、浏览器代理扩展、其他 VPN 同时启用时,不同请求可能走不同出口,登录 Cookie 和实时连接容易失效。
• 排除浏览器缓存。用隐私窗口或新建浏览器配置测试。若隐私窗口正常,问题可能来自旧缓存、扩展拦截或浏览器的独立 DNS 设置。
• 确认规则没有误伤。在线写作平台的主域名、资源域名和实时接口应统一指向同一策略组,避免一部分请求直连、一部分请求代理。

如果项目编译本身失败,先查看编译日志。缺少宏包、文件路径大小写不一致、参考文献工具链报错,都属于项目或编译环境问题,与 Clash 无关。只有在日志显示上传超时、连接中断或资源请求失败时,才继续检查代理链路。

验证清单:用最小测试定位问题

配置完成后,建议按照固定顺序做一次回归测试,每次只改变一个变量。这样可以区分规则、DNS、节点和应用自身的问题。

1. 保持规则模式,打开学术搜索页面,确认页面和登录流程正常。
2. 下载一个小型 PDF,再下载一个较大的公开论文文件,比较是否存在大小或持续时间相关的断流。
3. 在 Clash 日志中确认学术域名命中 Academic,学校门户和局域网地址命中 DIRECT。
4. 在 Zotero 中先同步元数据,再同步一个新附件,分别记录成功或失败的环节。
5. 在 Overleaf 中打开项目、修改一个无关紧要的字符并保存,观察实时保存和编译状态是否稳定。
6. 临时切换到另一个节点重复测试。若只有一个节点失败,保留规则不变,更换节点即可;若所有节点都失败,再检查规则和 DNS。

常见问题

配置落地后的维护原则

科研网络配置不需要追求规则数量最多,而要追求出口清晰、故障可定位。把学术平台统一指向 Academic,把 WebDAV 或附件服务单独抽出,把学校内网和局域网明确设为直连,再用日志验证每一类请求的实际命中结果。订阅更新后,重点检查策略组名称是否变化、节点是否仍可用、规则集是否成功更新。

日常使用保持规则模式即可;全局模式只用于短时间诊断,直连模式用于确认是否为代理造成的问题。涉及账号登录、文献同步和研究资料传输时,不要把订阅链接、访问令牌或私人项目内容粘贴到公开配置中。完成首次配置后,建议每隔一段时间重新测试论文下载、Zotero 附件同步和在线写作,避免节点或规则变化后才在截止日期前发现问题。