科研工作中的网络问题，通常不会以「完全无法上网」的形式出现。更常见的情况是：普通网页可以打开，Zotero 却无法同步；Google Scholar 能加载搜索结果，但点击出版社全文后反复超时；Overleaf 编辑器可以登录，编译时却卡在资源下载或长时间等待。不同应用使用的域名、连接方式和代理识别机制并不相同，因此仅仅打开系统代理，并不能保证整个科研工作流都稳定。

本文以 Clash 为统一的本地代理入口，从科研人员常见的文献检索、文献管理、协作写作和数据下载场景出发，说明如何规划规则分流、如何判断是否需要 TUN 模式，以及如何为 Zotero、Overleaf、浏览器和命令行工具分别设置代理。文中的域名和配置片段是通用示例，实际使用时应以你所在机构的网络政策、服务商规则和 Clash 连接日志为准。

科研网络为什么需要按工作流分流

研究者每天使用的网络服务具有明显的混合特征。学校内网、实验室服务器、校图书馆入口和国内镜像通常更适合直连；国际出版社、预印本平台、代码托管服务以及部分同步接口，则可能需要经过代理才能获得稳定连接。如果把所有流量都放入同一个全局代理，虽然配置简单，却可能造成校内系统登录变慢、局域网设备无法发现、内网 Git 推送失败，甚至触发机构安全系统的异常登录提醒。

更合理的方式是使用 Rule 规则模式：把明确需要代理的域名交给代理策略组，把可信的校园网、公司内网和本地服务保留为 DIRECT。规则分流还有一个重要优势，就是便于排障。你可以在 Clash 连接面板中看到某次 Zotero 请求到底命中了哪条规则，而不必凭感觉判断「代理是不是开了」。对于需要长时间运行的同步和编译任务，这种可观察性比单纯追求测速数字更加重要。

先把流量分成三类

配置之前，可以把常用服务分为三组。第一组是机构与本地资源，包括学校统一认证、图书馆内网、实验室 NAS、私有 Git、校园 VPN 地址和本地打印服务，这些域名通常应保持直连或使用机构指定的出口。第二组是学术公共资源，例如 Google Scholar、Crossref、部分预印本平台、国际出版社网站和开放数据仓库，这些服务对 DNS、TLS 握手和长连接质量较为敏感，适合统一交给稳定的代理组。第三组是协作与开发服务，包括 Overleaf、GitHub、Docker Hub、包管理仓库和云端 API，它们可能同时使用网页、WebSocket、静态资源和 API 域名，需要通过连接日志逐步补齐规则。

配置建议：不要一开始就收集一份巨大的「科研域名大全」。先记录自己实际访问过的主机名，再用 DOMAIN 或 DOMAIN-SUFFIX 精确添加，规则更容易维护，也不容易误代理无关流量。

Clash 基础设置：端口、模式与配置文件

无论使用 Clash Verge Rev、Mihomo Party 还是其他兼容客户端，第一步都是确认当前真正运行的配置文件。很多「规则没有生效」的问题，并不是 YAML 写错，而是用户编辑了订阅原文件，却实际加载了另一份 profile；或者订阅更新后覆盖了手写内容。打开客户端的配置页面，确认活动配置、内核状态和最后更新时间，再开始修改规则。

接着确认本机的 mixed-port。混合端口通常同时支持 HTTP 和 SOCKS5，适合浏览器、终端和多数开发工具使用。不同配置的端口可能是 7890、7897 或其他值，不能照抄示例。可以先执行一个简单的健康检查，判断本地 Clash 是否正在监听端口：

# Replace 7890 with your actual mixed-port
curl -I -x http://127.0.0.1:7890 https://example.org

如果命令立即返回 HTTP 响应，说明本机代理入口基本可用；如果提示连接被拒绝，应先检查 Clash 内核是否运行、端口是否记错，或者是否有其他软件占用了相同端口。此时不要急着调整 Zotero 或 Overleaf，因为应用层还没有机会把请求交给 Clash。

日常科研优先使用规则模式

规则模式适合大多数研究者。它可以让学校登录页、内网资源和本地开发服务保持直连，同时把明确的国际学术资源交给代理组。建议先关闭其他 VPN、网络加速器和重复的代理软件，只保留一条清晰的网络路径。确认浏览器、终端和 Clash 面板表现一致后，再逐步恢复其他工具。

全局模式可以作为短时间的对照测试。如果规则模式下某个服务失败，而全局模式下立即恢复，通常说明规则缺失、规则顺序不对或 DNS 判断存在问题。但全局模式不适合作为长期科研配置，因为它可能把校内系统、数据库下载和局域网流量全部绕到不必要的远程节点。

Zotero 代理配置与同步排障

Zotero 的网络行为不只有一个入口。它可能访问同步服务、附件存储、网页抓取目标、DOI 或元数据接口，以及用户在浏览器中打开的出版社页面。即使 Zotero 主程序可以登录，附件同步仍可能失败；即使网页端可以下载 PDF，Zotero Connector 也可能因为浏览器代理与桌面程序代理不一致而无法保存文献。因此，排查时应该把「登录」「元数据」「附件」「同步」分开验证。

先验证系统代理是否被 Zotero 读取

如果使用桌面客户端，优先在 Clash 中开启系统代理，然后完全退出并重新打开 Zotero。重启很重要，因为部分应用只在启动时读取代理环境或系统网络设置。打开同步操作时，同时观察 Clash 的连接列表，搜索 zotero、同步服务域名和附件存储域名。如果连接面板完全没有相关请求，可能是 Zotero 使用了缓存、请求尚未触发，或者应用绕过了系统代理。

如果连接出现但策略显示为 DIRECT，不要立刻认为 DIRECT 一定错误。首先确认该域名是否属于你所在机构可以直连的服务；如果它是国际同步或存储域名，并且直连反复超时，再把实际出现的域名加入代理规则。规则中应优先使用明确域名，而不是直接把所有云存储流量都代理出去。

同步失败时的检查顺序

  1. 确认系统时间、Zotero 账户状态和本地磁盘空间正常，避免把认证或存储问题误判为网络问题。
  2. 在 Clash 连接面板中触发一次手动同步，记录出现的真实域名和最终策略。
  3. 对显示为 DIRECT 且持续超时的域名添加精确规则，保存后重新加载配置。
  4. 切换代理策略组中的节点进行对照，区分规则错误、节点不可用和服务端限流。
  5. 如果只有附件失败，检查附件存储相关域名和 WebDAV 设置，不要只测试 Zotero 账户登录。

附件同步尤其容易受到长连接和大文件传输影响。一个节点能够打开网页，并不代表它适合连续上传数百 MB 的 PDF。遇到同步中断时，可以先用较小的附件进行测试，再观察连接是否在传输过程中被重置。若更换节点后立即改善，说明主要矛盾可能是线路质量，而不是 Zotero 配置本身。

Overleaf 协作与编译连接配置

Overleaf 的页面编辑、实时协作、项目静态资源和编译任务可能使用不同的请求路径。页面能打开，只能说明基础网页请求成功；如果编辑器频繁断开、同伴修改不能及时出现，或者编译过程中下载宏包失败，还需要继续观察 WebSocket、API 和资源请求。Clash 的连接面板可以帮助你确认这些请求是否都使用了同一个合适的代理策略。

浏览器端先使用规则代理

对于浏览器中的 Overleaf，通常先开启 Clash 系统代理或浏览器遵循的 HTTP 代理即可。打开项目后，连续进行几次小修改，观察实时保存和协作状态是否稳定。不要一上来打开 TUN，因为 TUN 会同时影响更多应用，出现问题时反而难以判断是浏览器、系统路由还是 Overleaf 本身造成的。

如果页面加载正常但编辑器不断显示离线，查看 Clash 连接列表中是否有 WebSocket 相关连接。某些配置会把网页主域名交给代理，却让静态资源或 API 子域名命中宽泛的 DIRECT 规则。此时应依据连接面板中的实际主机名补充规则，而不是只添加一个猜测的主域名。

编译失败要区分网络与项目错误

Overleaf 编译失败不一定是代理问题。LaTeX 语法错误、图片路径错误、宏包不存在、项目超出编译时间限制，都可能表现为「没有生成 PDF」。如果编译日志能够快速返回，并且明确指出某个宏包或命令错误，说明网络链路很可能已经正常。只有在日志长时间没有更新、资源下载阶段卡住或页面与编译服务失去连接时，才需要重点检查 Clash。

协作项目常常包含较大的图片、参考文献数据库和外部资源。编辑时可以先复制一份最小项目，只保留主文件和少量资源进行测试。最小项目能够正常编译，而完整项目失败，通常应回到项目结构、资源大小和编译设置排查；两个项目都在同一网络阶段卡住，才更像是节点或规则问题。

学术资源规则分流示例

下面的规则只用于说明结构，策略组名称必须替换为你当前配置中真实存在的名称。将自定义规则放在宽泛的 GEOIP、RULE-SET 或 MATCH 规则之前，否则前面的规则可能已经决定了最终策略。

# Academic and collaboration traffic
rules:
  - DOMAIN-SUFFIX,overleaf.com,RESEARCH-PROXY
  - DOMAIN-SUFFIX,zotero.org,RESEARCH-PROXY
  - DOMAIN-SUFFIX,scholar.google.com,RESEARCH-PROXY
  - DOMAIN-SUFFIX,crossref.org,RESEARCH-PROXY
  - DOMAIN-SUFFIX,doi.org,RESEARCH-PROXY
  - DOMAIN-SUFFIX,arxiv.org,RESEARCH-PROXY
  - DOMAIN-SUFFIX,github.com,RESEARCH-PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,RESEARCH-PROXY

不要机械地把所有出版社域名全部加入规则。不同出版商可能使用多个 CDN、身份认证域名和机构代理入口，最稳妥的办法是打开一篇需要访问的全文，在连接面板中记录实际出现的主机。对同一服务进行登录、打开 PDF、下载附件三种操作，通常能够收集到比搜索引擎列表更准确的规则集合。

什么时候应该启用 TUN 模式

TUN 模式通过虚拟网卡接管更底层的网络流量，适合无法读取系统代理、无法设置环境变量，或者由后台服务发起请求的程序。例如某些文献管理插件、容器中的编译工具、独立的同步进程和只使用原生 TCP 连接的应用，可能不会遵循系统 HTTP 代理。此时 TUN 可以减少「浏览器正常、后台程序失败」的差异。

但 TUN 不是越早启用越好。它会影响更多网络连接，也可能与学校 VPN、企业零信任客户端、Docker 虚拟网卡和其他路由软件冲突。启用之前应记录当前路由状态，并准备好关闭 TUN 的恢复路径。若开启后出现校园内网不可达、远程桌面断开或 DNS 解析异常，应先关闭 TUN，回到规则模式加显式应用代理的方案。

注意：不要同时运行多个会修改系统路由的 VPN、TUN 客户端或网络过滤工具。科研服务器登录失败时，先做单变量测试：只保留 Clash，确认问题后再逐一恢复其他网络组件。

TUN 的安全测试流程

  1. 导出或备份当前 Clash 配置，记录系统代理、DNS 和 mixed-port 设置。
  2. 关闭其他全局 VPN，启用 Clash TUN，并按照客户端提示授予必要的网络权限。
  3. 先测试学校内网、本地 Git 和实验室服务器，再测试 Zotero 同步和 Overleaf。
  4. 在连接面板检查流量是否出现重复代理、循环连接或大量 DNS 请求。
  5. 如果 TUN 造成内网异常，立即回退到规则模式，改用应用级代理解决单个进程。

命令行工具、Git 与数据下载

科研工作经常需要使用 Git、Python、R、命令行下载器或远程计算脚本。这些工具通常不会自动读取桌面客户端的系统代理，因此需要在启动它们的终端中显式设置环境变量。可以在项目级脚本中配置，而不是把代理永久写入所有 shell，从而避免访问校内 Git 或私有包仓库时误走远程节点。

# Use the actual Clash mixed-port
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,.local,10.0.0.0/8,192.168.0.0/16

NO_PROXY 应根据实验室网络调整。公司或学校的私有域名、内网 IP 段和本地服务一般不需要经过代理；但不要把过大的公共域名后缀写入其中，否则可能把本来需要代理的学术服务排除掉。使用 Python、Node 或容器时，还要确认变量确实传递到了对应的运行环境。可以先用 env | grep -i proxy 检查当前终端，再启动脚本。

DNS、连接日志与常见误判

DNS 是科研资源访问中经常被忽略的一环。规则本身写对了，如果域名解析在代理接管之前完成，仍可能得到不合适的地址，最终表现为 TLS 超时或连接被重置。对于使用 fake-ip、Redir-Host 或增强 DNS 模式的 Clash 配置，不要随意复制不同教程中的 DNS 段落。先确认当前内核支持的字段，再用日志观察域名解析和连接策略。

排查时建议遵循「域名、策略、节点、响应」四个维度。域名不对，说明应用访问了你没有想到的辅助主机；策略不对，说明规则顺序或规则集合有问题；节点不稳定，说明出口质量需要调整；策略和节点都正常但服务返回 401、403 或 429，则应转向账户、权限和服务端限制排查。将这些问题分开，可以避免反复修改 YAML 却没有实际进展。

一套可重复的验证清单

完成配置后，不要只打开一个网页就宣布成功。建议按照真实科研工作流进行验证：先访问学术搜索页面，打开一篇全文，再执行一次 Zotero 元数据抓取和小附件同步，最后在 Overleaf 中修改内容并触发一次短编译。每一步都在 Clash 面板记录域名和策略，形成一份属于自己的连接清单。

  • 浏览器：检查搜索、登录、PDF 加载和静态资源是否都能在合理时间内完成。
  • Zotero：分别测试账户同步、元数据抓取和附件上传，不要只看登录是否成功。
  • Overleaf：测试编辑保存、多人协作状态、项目资源加载和最小项目编译。
  • 终端：检查 Git、包管理器和数据下载命令是否继承了正确的代理变量。
  • 内网：确认学校认证、实验室服务器、私有 Git 和本地设备仍能按预期访问。

如果只有一个服务失败，优先查看该服务的实际连接日志；如果所有外部服务同时失败，先检查 Clash 内核、节点和本机端口；如果外部服务正常而内网失败，则重点检查 TUN、DNS 和路由冲突。每次只改一个变量，并在修改前后保留测试结果，后续更换订阅或设备时会省下大量时间。

长期维护：让配置跟着研究项目变化

科研项目周期往往很长，网络配置也会随着机构认证、实验室服务器、协作平台和数据源变化。建议把自定义规则放在独立的 Override 或 Merge 文件中，不要直接修改每次都会自动更新的订阅原文件。为每条自定义规则写简短说明，记录它服务于哪个项目、何时添加以及出现过什么问题。这样在规则失效或团队成员接手时，能够快速判断哪些条目仍然必要。

订阅更新后要重新检查规则顺序，因为新的 RULE-SET 可能插入在自定义规则之前。节点选择也不应只看延迟，Zotero 附件同步和 Overleaf 编译更关注丢包、持续传输能力与长连接稳定性。每隔一段时间用固定的测试项目复测，比临近投稿截止日期才发现配置失效更加稳妥。对于重要论文项目，还可以准备一个不依赖复杂规则的备用配置，用于紧急提交和协作。

为什么科研工作流适合使用 Clash 管理

科研人员需要的并不是一个永远全局开启的网络开关，而是能够解释、调整并长期维护的分流系统。Clash 可以把 Zotero、Overleaf、学术搜索、代码托管和内网服务放在同一套可观察的规则框架中；出现问题时，连接面板能够显示实际域名和策略，TUN 又为不遵循系统代理的进程提供了补充路径。对需要同时兼顾校园资源、实验室环境和国际协作平台的研究者来说，这种按域名和应用逐步收敛的方式，通常比只依赖浏览器插件或全局 VPN 更容易定位问题。

一些只提供单一全局隧道的工具，配置成本看似更低，却常常无法解释某个请求为什么失败，也很难在访问校内 Git、实验室服务器和国际出版社时同时保持合适路径；单纯的浏览器扩展则覆盖不到 Zotero 后台同步、命令行脚本和 Overleaf 相关进程。相比之下，Clash 的规则分流、连接日志和 TUN 组合可以按需扩展，帮助你把科研资源访问从「反复重试」变成可验证、可维护的网络配置。如果你正在寻找适用于多平台科研工作的代理客户端，可以从下载页获取 Clash，并按照本文的端口、规则与验证步骤逐项落地。

前往下载页获取安装包

立即免费下载 Clash，开启流畅上网新体验 →