先拆分科研工作流：网页访问、文献同步和附件存储不是一条链路

Google Scholar、arXiv、IEEE Xplore、Zotero 与 Overleaf 都可能出现在同一项研究中，但它们发起请求的应用、域名和同步方式并不相同。浏览器能打开论文页面，不代表 Zotero 桌面端已经能同步；Zotero 条目同步成功，也不代表附件文件已上传；Overleaf 项目页面能加载，也不代表 WebSocket 连接和协作更新正常。排查时先按“哪个程序、访问哪个域名、执行什么操作”拆分，不要一开始就把所有科研流量都改成全局代理。

建议先使用 Rule（规则）模式，在实际生效的策略组里固定一个可用节点，再逐个验证目标。系统代理只影响遵循系统代理设置的应用；TUN 可以接管更多未配置代理的程序，但也会增加路由、DNS 和权限方面的变量。初次配置时，先不同时启用浏览器代理扩展、系统代理、TUN 和另一套 VPN。

科研服务可能受到机构授权、出版商访问策略、地区政策或账号权限限制。代理配置只改变网络请求的路径，不会替代机构登录、校园网授权、图书馆认证或服务条款。使用前应遵守所在机构和目标服务的规定；遇到权限错误时，先核对账号与机构入口，不要把改变出口地址当作授权手段。

为学术域名分流：范围尽量小，规则顺序要明确

域名规则应优先匹配具体服务，不要为了 Scholar 或某篇 IEEE 论文直接把所有 Google 或整个互联网都塞进同一策略组。过宽的 DOMAIN-SUFFIX,google.com 可能改变 Gmail、云端硬盘、登录和其他服务的出口，扩大排查范围；而只匹配主站也可能漏掉页面实际调用的认证或资源域名。先从 Connections 观察真实请求，再按需要增加规则。

服务可先观察的域名常见注意点
Google Scholarscholar.google.com搜索结果、登录跳转和引用导出可能涉及其他 Google 域名；按实际连接补充，不要默认代理整个 Google 域名空间。
arXivarxiv.org论文摘要、PDF 下载和 API 请求的表现可能不同；区分页面失败、下载失败与本地 PDF 阅读器问题。
IEEE Xploreieeexplore.ieee.org论文页面、登录认证与机构访问可能调用不同域名；账号权限或机构登录失败不等于节点故障。
Zoteroapi.zotero.org、sync.zotero.org条目同步与附件存储并非总是同一请求；若配置 WebDAV，还需检查用户填写的 WebDAV 主机。
Overleafoverleaf.com 及其子域名编辑器还依赖脚本、资源与实时连接；只允许主页面加载，可能仍无法协作或保存。

下方只是供合并参考的局部规则片段，不是完整配置，也不包含节点、代理组或订阅。把 科研代理 替换为当前配置里真实存在的策略组名称；若配置没有这个组，就先使用已经存在且可手动选择节点的组。规则要放在会提前匹配这些域名的宽泛规则之前，并检查配置校验结果。

# 局部规则示例：合并进现有配置，不要覆盖整份订阅
rules:
  - DOMAIN,scholar.google.com,科研代理
  - DOMAIN-SUFFIX,arxiv.org,科研代理
  - DOMAIN,ieeexplore.ieee.org,科研代理
  - DOMAIN,api.zotero.org,科研代理
  - DOMAIN,sync.zotero.org,科研代理
  - DOMAIN-SUFFIX,overleaf.com,科研代理

DOMAIN 用于匹配指定的完整主机名，DOMAIN-SUFFIX 用于匹配域名及其子域名。示例中的规则并不保证覆盖服务实际使用的全部主机，也不应被理解为固定的官方域名清单。若连接记录显示资源请求走了其他主机，先确认它属于目标服务，再新增范围尽可能小的规则。若请求被规则送入正确策略组但仍超时，继续查看代理链和错误日志，不要无止境添加域名。

浏览器与 Overleaf：页面、静态资源和实时协作分开验证

Google Scholar、arXiv、IEEE Xplore 和 Overleaf 通常先通过浏览器使用。先确认浏览器读取了系统代理设置；Firefox 的手动代理、Chrome 或 Edge 的扩展、PAC 脚本以及组织下发的策略，都可能改变请求入口。测试时可以暂时停用自行安装的代理扩展，并关闭相关标签页后重新打开。受机构管理的浏览器设置不要擅自覆盖。

  1. 在客户端 Profiles（配置）里确认当前激活的是预期配置，进入 Proxies（代理）确认规则实际引用的策略组，并手动固定一个节点作为基线。
  2. 开启系统代理，使用浏览器重新打开目标页面。测试前记下时间和完整域名，避免把缓存页面误认为新请求成功。
  3. 打开客户端 Connections（连接），检查请求是否出现、命中了哪条规则、最终选择了哪个策略组或节点。若显示 DIRECT，先检查规则顺序与浏览器代理设置。
  4. 在 Overleaf 中分别测试项目首页、打开文档、编辑后保存和多人协作。仅首页可见并不能证明实时连接正常。

Overleaf 编辑器需要加载多类资源，并可能建立实时连接。若页面外壳能打开但编辑器持续转圈，查看浏览器开发者工具的 Network（网络）面板，区分主文档、脚本资源、接口请求和 WebSocket 是否失败。若失败请求的域名没有经过预期策略组，按真实请求补充精确规则；若所有请求均已走代理但只有实时连接失败，则检查浏览器扩展、企业防火墙、节点稳定性与服务端状态。

Google Scholar 的搜索结果可点击，但跳转出版商页面失败时，分别检查 Scholar 页面请求和目标出版商请求。Scholar 提供的链接可能指向机构代理入口、登录系统或出版商域名；规则命中正确不表示账号已经获得全文权限。若机构要求通过图书馆链接或校园身份认证访问，应使用机构指定入口完成授权。

浏览器页面有时会从缓存中显示旧内容。对照测试可在开发者工具中临时启用 Disable cache（停用缓存），保持工具打开并重新加载。测试完成后恢复原设置。不要因为单个静态资源被拦截就把整个浏览器设为全局代理；先确定资源来源及其与目标功能的关系。

Zotero：把条目同步、附件同步和 WebDAV 分开诊断

Zotero 的文献条目同步与附件文件同步是不同环节。条目可能已经上传，但 PDF 等附件仍在本地；反过来，附件也可能已存于 WebDAV，而 Zotero 账号的条目同步尚未完成。先在 Zotero 的同步状态与活动日志中确认失败对象，再判断应检查 API 请求、附件存储还是本地文件权限。

  • 条目同步失败：查看 Zotero 账号登录状态、同步错误文本和客户端日志；在 Clash Connections 中检查是否出现 api.zotero.org 或 sync.zotero.org 相关请求，以及规则是否命中预期策略。
  • 附件没有同步：确认 Zotero 的文件同步设置、存储服务选择和配额状态。若使用 WebDAV，检查 Zotero 中填写的服务器地址、账号、密码及该主机对应的网络连接。
  • 附件下载失败：比较条目元数据是否已同步、附件是否存在远端记录、客户端是否有本地写入权限。不要仅凭条目列表出现就判断 PDF 已经上传。
  • 重复提示或长时间等待：先等待当前任务结束并查看日志，不要连续点击同步或删除本地数据库。操作前备份 Zotero 数据目录，避免把网络问题变成数据恢复问题。

桌面应用是否遵循系统代理，取决于操作系统、客户端网络设置和具体版本。先用一次受控测试观察 Connections；如果 Zotero 发起同步时完全没有对应连接，检查应用是否使用独立代理设置、是否需要重启，或是否需要由 TUN 接管。启用 TUN 前先记录原路由状态，并确认没有其他 VPN 或安全软件同时管理虚拟网卡。不要把公开的订阅地址、Zotero 密码、WebDAV 凭据或含个人信息的日志发到公开页面。

若错误明确显示认证失败、配额不足、文件冲突或无权限，代理通常不是第一检查项。核对账号、同步选项、存储空间和客户端提示；网络路径正常而服务拒绝操作时，继续切换节点通常不会解决根因。可以先在官方客户端界面完成一次账号状态检查，再用一条新建的测试条目验证同步，避免反复操作重要文献库。

按现象定位故障：从接管入口到服务端响应逐层缩小范围

遇到加载异常或同步失败，采用一次只改变一个变量的对照方法。先固定配置、节点和测试目标，依次检查请求有没有进入 Clash、规则是否命中、策略组最终选择了什么、远端请求返回了什么。这样能够区分本地代理问题、域名分流问题、节点问题和应用自身问题。

现象优先判断下一步操作
页面没有新连接记录请求可能未进入 Clash，或命中缓存检查系统代理、浏览器扩展与缓存；关闭页面后重新发起请求。
连接记录显示 DIRECT规则没有命中预期代理组，或规则顺序过晚检查匹配域名、规则优先级和当前模式，不要先更换所有节点。
已选代理节点但连接超时节点链路、DNS、目标服务或本地网络存在问题查看 Logs（日志）中的错误；固定同一目标，换一个候选节点作对照。
Scholar 可用，出版商页面失败跳转域名、机构认证或出版商服务不同核对跳转后的主机、机构登录状态及账号权限。
Zotero 条目同步，附件缺失条目同步和文件同步状态不同检查附件同步方式、存储配额、WebDAV 地址与文件状态。
Overleaf 页面打开但协作不更新实时连接或编辑器资源可能失败检查 Network 面板的失败请求、浏览器扩展与 Connections 记录。

必要时用终端建立对照，但端口必须以客户端当前配置为准。以下命令仅适用于 HTTP 代理监听端口为 7890 的示例；如果配置使用其他端口，应先替换为实际值。它测试的是显式代理请求，不代表 Zotero 或浏览器自动采用系统代理。

curl -I -x http://127.0.0.1:7890 https://arxiv.org

若命令提示连接被拒绝，先检查内核是否运行、端口是否监听，以及填入的是否为代理端口而不是控制端口。若显式代理成功、浏览器无对应连接，重点排查浏览器入口；若浏览器请求已走预期节点但仍失败，再查看 DNS 结果、握手错误、HTTP 状态码和服务端提示。curl -I 使用 HEAD 请求，部分网站不支持或限制 HEAD；遇到方法不支持时，不能据此断定代理链路故障，可改用浏览器实际请求对照。

最后，保存一份能复现问题的最小记录：操作系统与客户端版本、Clash 或 mihomo 内核版本、Rule 或 TUN 状态、目标主机、失败时间、命中规则、代理链和错误文本。分享日志前删除订阅令牌、账号标识、内网地址及请求中的敏感参数。按层定位后，再决定是否需要调整分流规则、修复应用设置或联系机构与服务支持。