科研人员用Clash访问Scholar与arXiv：学术检索分流配置指南

先按访问场景分流，不要把所有学术流量一概代理

学术检索、论文下载、文献同步和校园网服务，访问路径并不相同。Google Scholar、arXiv 或 IEEE Xplore 页面打不开时，原因可能是当前网络出口、域名解析、机构认证跳转，也可能是目标服务本身暂时不可用。分流的目标是让需要代理的公开学术资源走指定策略组，同时让图书馆内网、校园统一身份认证和校内数据库按机构要求连接。

Clash 客户端负责导入配置、切换策略和管理系统代理；Clash 或 mihomo 内核按规则处理已进入代理的连接。规则只决定流量进入内核后使用哪个出口，不能代替学校或出版商提供的访问资格。订阅节点也不会自动获得学校图书馆的校外访问权限，遇到登录限制时应遵循所在机构的认证流程。

• 检索页面：可将 Google Scholar、arXiv 等域名送入学术策略组，便于按当前网络情况选择出口。
• 机构资源：图书馆入口、校园网域名、校内数据库及统一身份认证服务，通常应优先遵循学校给出的网络要求。若要求校内网络或学校 VPN，不要用代理策略替代。
• 协作与同步：Zotero 同步、Overleaf 项目编辑和机构单点登录涉及的域名可能与论文页面不同，应以客户端连接记录和服务商说明为准，逐项验证。

用精确域名规则建立学术策略组

建议先在现有配置中确认一个可用的手动选择策略组，再让学术域名指向该组。策略组名称必须与配置中的名称完全一致，包括空格和大小写；下面的 学术代理 是示例名称，不会因为复制规则而自动创建。若日常使用的主策略组已经能切换节点，也可以直接把规则出口替换成该组。

proxy-groups:
  - name: 学术代理
    type: select
    proxies:
      - 节点选择
      - DIRECT

rules:
  - DOMAIN,scholar.google.com,学术代理
  - DOMAIN-SUFFIX,arxiv.org,学术代理
  - DOMAIN,ieeexplore.ieee.org,学术代理
  - DOMAIN-SUFFIX,lib.example.edu,DIRECT
  - MATCH,节点选择

此片段用于说明规则结构，不应直接覆盖订阅的完整配置。lib.example.edu 是示例域名，需替换为学校实际提供的图书馆或校园服务域名；如果没有确定的域名，就不要保留这条示例规则。把规则加入客户端支持的配置覆写或合并位置，并确认最终运行配置中它们位于宽泛规则之前。不同客户端菜单名称不同，可在配置编辑页或内核日志中确认最终规则。

• DOMAIN 只匹配指定的完整域名，适合 scholar.google.com 这类明确目标。
• DOMAIN-SUFFIX 匹配域名本身及其子域名。arxiv.org 规则能覆盖其子域名，但不应据此把所有 Google 或所有教育类域名都纳入代理。
• MATCH 是兜底规则，通常应放在规则列表末尾。若更早的规则已匹配，后面的兜底不会再决定该连接。
• DIRECT 表示直连，不代表连接一定成功；校外直连能否访问校园资源取决于学校的网络与认证政策。

不建议一开始就添加宽泛的 DOMAIN-SUFFIX,google.com 或 DOMAIN-SUFFIX,edu。它们会影响大量与论文检索无关的服务，可能造成登录跳转、云端文件、学校系统走错路径，也会让故障定位更困难。若 Scholar 页面能打开但缩略图、导出或跳转链接失败，先查看连接记录里实际出现的域名，再决定是否需要增加精确规则。

动手验证：按检索、下载、同步逐项检查

下面这组步骤适用于 Clash Verge、Clash Verge Rev 等带连接记录的桌面客户端，也适用于能查看 mihomo 连接与日志的环境。先记录客户端版本、内核版本、当前模式和使用的策略组；测试期间不要同时更换节点、切换规则模式、启用 TUN 和修改 DNS，否则很难判断是哪项改变带来结果。

1. 确认入口正常：检查客户端当前配置已启用、内核正在运行，并确认系统代理或 TUN 至少有一种接管方式处于预期状态。若使用浏览器显式代理，确认浏览器读取的是正确端口；不要把控制面板端口当作代理端口。
2. 固定测试条件：暂时选定一个学术策略组节点，关闭自动测速带来的频繁切换，或记录当前选中节点。先访问 Scholar，再打开 arXiv 的论文摘要页，最后测试 IEEE Xplore 页面。
3. 核对连接记录：按域名筛选客户端的「连接」或「日志」页面，查看目标域名是否出现、命中的规则是什么、最终策略是否为「学术代理」，以及组内实际选中了哪个节点。页面能打开但连接记录没有对应请求时，可能命中了缓存，或浏览器没有经过当前代理入口。
4. 测试文件获取：从 arXiv 论文页打开 PDF，观察浏览器下载是否完成；随后在 IEEE 页面按正常授权流程测试论文链接。不要仅凭首页加载成功就认定 PDF 下载链路也正常。
5. 复测机构服务：另开校园图书馆或学校统一身份认证页面，确认其域名按机构要求连接。若需要校园网或学校 VPN，按学校说明连接；不要因学术策略组可用就将校内认证流量强行改道。
6. 一次只改一项：若请求失败，先记录时间、域名、命中规则和错误提示，再只更换节点或调整一条规则复测。这样可以区分代理入口故障、规则顺序错误、节点不可达和网站认证问题。

浏览器可能缓存页面、Cookie 或重定向结果。对照测试时，可使用新的隐私窗口重新登录，但不要在不可信设备上保存机构账号。若服务返回地区、访问频率或授权错误，先看服务提示与学校帮助页面；单纯增加代理域名规则不一定能解决这类问题。

检查 Zotero 与 Overleaf：它们不是论文网页的附属连接

Zotero 的文献条目可以在本地管理，附件、同步和元数据获取则可能产生不同的网络请求。先区分“网页无法打开”“文献信息抓取失败”“附件下载失败”和“库同步停滞”，分别查看浏览器或 Zotero 的错误提示。Zotero 桌面端与浏览器连接器也可能使用不同的系统代理行为，因此网页能访问不代表应用内同步一定经过同一出口。

• 文献信息抓取：从 Scholar 或出版商页面保存条目后，检查作者、标题、年份和 DOI 是否正确。若连接器只保存了网页书签，先确认当前页面的元数据是否可读，不要立刻归因于代理规则。
• 附件与同步：在 Zotero 的同步设置中确认账户状态及同步选项，再观察同步错误信息。若需要核对流量路径，可在客户端连接记录中寻找同步发生时的新连接域名；只为确认过的域名添加规则，不要猜测并代理整个云服务域名空间。
• Overleaf 项目：先在浏览器打开项目列表，再测试编辑器加载、编译和文件上传。登录可能跳转到机构身份提供方；出现循环跳转时，记录跳转域名并检查浏览器 Cookie、时间设置和机构授权流程。
• 校园网络服务：如果学校要求通过校园网或校方 VPN 使用数据库，优先遵循学校的远程访问指南。校园 VPN 与 Clash 的 TUN 都可能管理系统流量，启用两者前应确认学校支持的组合方式，避免路由冲突或认证请求走错出口。

如果 Zotero 或 Overleaf 的请求没有出现在 Clash 连接记录中，先检查应用是否读取系统代理，以及当前是否使用了可接管该应用流量的模式。桌面客户端的系统代理通常只影响遵循系统设置的程序；TUN 的接管范围也受路由、排除项和权限影响。不要仅为让一个应用走代理就同时叠加多个代理客户端。

维护规则：最小范围、可回滚、按日志调整

学术服务的登录流程、文件分发和 CDN 可能变化，规则不宜一次写成覆盖多个平台的大清单。建议把自定义规则集中放在客户端支持的覆写区域，保留原订阅与覆写的备份，并在订阅更新后检查最终规则仍然存在。若客户端提供配置检查或内核启动日志，保存前先确认语法与策略组名称有效。

• 规则生效但出口不对：在连接详情中确认命中的规则和组内节点。若使用全局模式，规则分流可能不会按预期发挥作用；切回规则模式后再比较。
• 访问速度忽快忽慢：固定节点和测试目标，多次复测；不要把单次延迟测试结果当作 PDF 下载速度。文件传输还受目标站点、线路拥塞和服务端限制影响。
• 认证后仍提示无权限：检查当前账号是否属于授权机构、是否需要学校 VPN 或指定代理入口。网络可达与内容授权是两个不同条件。
• 规则更新后失效：对照连接日志中的实际域名与规则顺序，确认自定义规则没有被配置更新覆盖，也没有被更早的规则截获。
• 需要回退：恢复最近一份有效覆写或移除新增规则，重新加载配置并测试原有校园服务。不要同时删除订阅、清空所有规则和重置 DNS，避免扩大故障范围。

完成配置后，建议保留一份简短记录：客户端与内核版本、规则模式、学术策略组名称、已验证的域名、测试时间和结果。不要记录节点密码或订阅令牌。需要进一步了解配置导入、代理模式与规则基础时，可查看使用指南；选择或安装客户端可前往客户端下载页。