科研人员在日常工作中往往需要同时处理文献检索、全文下载、代码或数据协作、参考文献同步和论文排版。Google Scholar、arXiv、IEEE Xplore、Overleaf、Zotero WebDAV 或云端同步服务的连接特点并不相同：有的网站依赖多个静态资源域名，有的需要稳定的 HTTPS 长连接，有的在登录、下载和同步阶段使用不同的域名。只把所有流量粗略地切换为全局代理，可能带来页面加载变慢、机构网站访问异常、局域网服务不可用或 Zotero 同步反复重试等问题。
更适合科研工作流的做法，是先在 v2rayN 中确认节点和 Xray 内核正常，再按域名建立“学术站点代理、国内与机构资源直连、其他流量按需处理”的分流结构。对于 Zotero、浏览器和协作工具，还要区分系统代理能覆盖的流量与必须使用应用代理或 TUN 模式接管的流量。本文以 Windows 桌面环境为主，结合 2026 年常见的 v2rayN 操作路径，说明如何配置、验证和维护这一套工作流。
从 v2rayN 节点选择开始，逐步完成 Google Scholar、arXiv、IEEE Xplore 和 Overleaf 的按域名代理，说明 Zotero 同步与浏览器访问的差异，并给出一套可复用的验证顺序，帮助科研人员减少检索页面、PDF 下载和协作同步中断。
先按科研工作流拆分访问目标
配置分流前不要急着收集一长串域名。更有效的方法，是按任务观察请求链路。文献检索通常由搜索页面、静态脚本、验证码或登录服务共同组成；论文下载可能跳转到出版社、机构认证或内容分发域名；Zotero 同步还可能访问账户服务、同步接口和 WebDAV 存储；Overleaf 则需要登录、项目编辑器、实时协作和编译资源保持稳定连接。若只添加一个主域名，页面仍可能出现空白、按钮失效或 PDF 下载失败。
建议把目标分成三组。第一组是明确需要代理的学术服务，例如 scholar.google.com、arxiv.org、ieeexplore.ieee.org 和 overleaf.com。第二组是应当保持直连的本地资源，包括学校内网、图书馆馆藏入口、实验室服务器、NAS、打印服务和路由器管理地址。第三组是暂时不确定的域名，先通过日志确认，再决定加入代理或直连规则。不要把所有包含“学术”字样的域名都交给代理，因为出版商页面经常会跳转到机构认证系统，实际访问权限仍取决于机构网络或登录状态。
结论：先按任务验证，再按域名扩展
一个主域名能打开，只能证明入口可达；只有搜索、登录、全文下载和同步分别验证成功，才能说明配置真正覆盖了科研工作流。
在 v2rayN 中建立按域名分流
首先打开 v2rayN，确认主界面底部显示 Xray 内核正在运行，并选中一条延迟稳定、近期测试成功的服务器。进入“设置”→“参数设置”或当前版本对应的路由设置区域，先确认本地 HTTP 和 SOCKS 监听端口。常见默认值可能是 HTTP 10809、SOCKS 10808，但不同版本或本机其他软件可能已经占用这些端口，不能只凭记忆填写。保存前记下实际端口，后续浏览器和 Zotero 排查都要用到它。
确认活动节点
在服务器列表选中目标节点，执行“设为活动服务器”，再用“测试服务器”或延迟测试确认连接不是旧配置。
开启系统代理
从主界面的系统代理菜单开启 HTTP 代理，确认代理模式不是“清除系统代理”。浏览器随后应能读取 v2rayN 写入的本地端口。
选择路由模式
进入“设置”→“参数设置”→“路由设置”，选择规则模式，而不是长期使用全局模式作为最终方案。
加入学术域名
把 Google Scholar、arXiv、IEEE Xplore、Overleaf 的主域名及实际日志中出现的资源域名加入代理规则。
保存并重启内核
保存参数后重启 Xray 内核，打开日志窗口，再依次访问搜索页、文章页、PDF 和协作项目，记录每一步结果。
规则的排列顺序非常重要。通常应先处理局域网和本机地址，再处理明确的直连例外，然后匹配学术服务，最后使用代理作为兜底或仅对指定目标代理。若使用自定义路由文件，可以把规则思路表达为：
geoip:private → direct
学校内网与实验室域名 → direct
scholar.google.com → proxy
arxiv.org → proxy
ieeexplore.ieee.org → proxy
overleaf.com → proxy
其他目标 → 按个人策略处理域名匹配可以采用完整域名、域名后缀或客户端支持的域名规则。完整域名更精确，适合先验证；后缀匹配覆盖面更大，但也可能把不需要代理的相关服务一并纳入。配置 google.com 这类较宽的后缀时，应考虑搜索、登录、静态资源和其他服务会共享域名的情况。若目标站点使用多个子域名，优先根据 Xray 日志补充缺失项，而不是一次性添加大量未经确认的域名。
浏览器、Zotero 与 Overleaf 的接管差异
浏览器通常能够较好地遵循 Windows 系统代理设置，但并非所有浏览器扩展、下载器和独立程序都会完全采用相同的代理来源。先在浏览器中打开一个普通直连站点，再访问 Google Scholar，观察 v2rayN 日志是否出现对应域名。如果页面主体可以显示而图片、脚本或登录按钮失效，说明主域名已命中，但资源域名没有进入同一出站，或浏览器缓存了部分旧连接。清理目标站点缓存、重新打开页面，并根据日志补充必要域名，通常比直接切换全局模式更容易定位。
arXiv 的检索页、摘要页和 PDF 下载可能表现不同。摘要页成功不代表 PDF 一定成功，因为下载请求可能经过不同的资源路径或重定向地址。验证时应至少完成一次关键词搜索、打开摘要、下载一个小型 PDF，并检查浏览器下载是否持续增长。若只有 PDF 失败，先查看日志中的最终目标域名和端口；不要马上修改 VMess、VLESS、TLS 或 Reality 参数，因为页面访问正常时，节点握手通常已经完成。
IEEE Xplore 还可能涉及登录、机构认证、引用导出和全文下载等不同请求。学校授权入口与公共检索入口不一定使用相同的域名。如果机构要求从指定图书馆入口登录，应保留该入口的认证流程，不要假设把所有相关域名都代理后就能获得机构权限。登录页面循环跳转时，可以分别测试直连和代理路径，查看系统时间、浏览器 Cookie、认证域名以及机构网络要求。
浏览器检索
- 代理来源
- 系统 HTTP 代理
- 常见端口
- 127.0.0.1:10809
- 验证内容
- 搜索、摘要、PDF
页面与下载应分别观察日志，不要只测试首页。
Zotero 同步
- 账户同步
- 应用自身请求
- 文件同步
- WebDAV 或服务接口
- 验证内容
- 条目、附件、冲突
应用未读取系统代理时，需要在应用设置中单独确认。
Zotero 的同步分为文献条目同步与附件文件同步，二者出现的网络请求和故障提示可能不同。先执行一次仅同步条目的操作，确认标题、作者、标签等元数据能够更新；再同步一份小型 PDF 附件，观察是否出现重复重试或认证错误。若条目可以同步而附件失败，应检查文件同步服务地址、WebDAV 用户名和密码、存储空间及应用代理设置，不要重复修改 v2rayN 节点。若 Zotero 完全没有出现在 v2rayN 日志中，说明它可能没有使用系统代理，或同步请求被应用自己的网络组件处理。
Overleaf 属于持续交互型服务，编辑器打开、项目文件加载、实时保存和编译日志可能由多个连接共同完成。打开项目后先等待文件树加载，再修改一处无关紧要的文本并保存，最后执行一次短文档编译。若编辑器显示已连接但保存延迟很大，观察日志中是否存在长连接被频繁断开。此时稳定节点、合理的路由范围和不反复切换代理模式比单次速度测试更重要。
用日志和分层测试确认配置有效
测试应该从低成本项目开始，而不是一开始下载大型论文或批量同步附件。先确认 v2rayN 内核状态，再确认浏览器读取本地代理，随后测试域名规则，最后测试具体应用。每次只修改一项设置，并在修改后重新建立连接，才能把结果对应到原因。
| 测试对象 | 操作 | 成功标准 | 失败时优先检查 |
|---|---|---|---|
| 本地端口 | 确认 v2rayN 监听 10809 或实际端口 | 内核运行且端口未被占用 | 内核状态、端口冲突、防火墙 |
| Google Scholar | 搜索关键词并打开结果 | 页面、脚本和结果链接完整 | 域名规则、浏览器代理、验证码 |
| arXiv PDF | 打开摘要并下载小型文件 | 下载持续完成且文件可打开 | 重定向域名、节点稳定性 |
| IEEE Xplore | 登录并访问授权全文 | 认证状态保持、全文请求成功 | 机构权限、Cookie、认证路径 |
| Zotero | 先同步条目再同步附件 | 条目更新、附件不反复重试 | 应用代理、WebDAV、账户状态 |
| Overleaf | 加载项目、保存并短编译 | 文件树、保存和编译均正常 | 长连接、资源域名、节点丢包 |
常见日志可以帮助区分故障层。出现 connection refused 时，通常要检查目标端口或远端服务是否监听；出现 i/o timeout，应比较不同节点、不同网络和不同目标；出现 tls handshake error，再核对服务器名称、证书链和系统时间；出现 no route to host 或 DNS 解析失败，则先处理地址解析和路由。若日志显示请求已经通过代理出站，但浏览器仍然报错，应进一步查看 HTTP 状态码、重定向地址和应用自身的登录状态。
报错: i/o timeout
原因与解法:连接在限定时间内没有完成，可能是节点拥塞、目标域名未命中规则或远端端口不可达——先用同一节点访问其他代理目标，再根据日志确认最终域名。
报错: proxyconnect tcp: connection refused
原因与解法:浏览器连接不到本机代理端口——检查 v2rayN 是否运行、系统代理端口是否仍为 10809，以及是否有其他程序占用该端口。
报错: failed to parse response
原因与解法:应用收到的内容不是预期格式，常见于认证页、拦截页或错误重定向——在浏览器中直接确认服务地址、登录状态和实际返回页面。
为了减少长期维护成本，可以把验证结果记录成一张小表：目标域名、访问用途、当前出站、最后成功时间和备注。每次更新订阅后只需复测四类关键任务，而不必重新测试所有网站。若某个域名连续一周没有使用，也可以暂时移出自定义规则，避免规则列表越来越宽。对于公开 Wi-Fi、实验室网络和家庭网络，分别记录一次结果，有助于判断问题来自本地网络限制还是节点自身。
Google Scholar 首页能开，搜索结果却空白怎么办？
先打开 v2rayN 日志，确认搜索请求及脚本域名是否命中同一代理出站；再清理站点缓存并重新建立浏览器连接，不要先改核心协议。
Zotero 条目能同步，PDF 附件却一直失败怎么办？
把条目同步和附件同步分开测试，检查文件同步服务的地址、存储空间与应用代理设置；若日志没有请求记录，优先查看 Zotero 的网络设置。
Overleaf 项目打开后经常掉线怎么办？
固定一个丢包较低的节点，确认项目域名和资源域名没有被直连规则覆盖，再测试保存和短编译；不要在编辑过程中频繁切换节点。
是否应该一直使用全局代理？
全局模式适合短时间确认节点是否可用，长期科研工作更建议使用规则模式，把学术服务、机构入口和本地资源分别处理。
长期使用时的维护与安全习惯
科研资料通常包含未公开论文、项目数据、内部讨论和个人账户信息。代理配置完成后，应避免在公共页面粘贴订阅链接、节点分享链接、Zotero 密码或机构认证信息。v2rayN 日志中可能出现请求域名和错误详情，分享日志前应删除账户标识、访问令牌、内网地址及完整 URL。订阅更新地址也应视为凭据管理，不要把它写入公开笔记或团队共享文档。
更新订阅后要检查三项内容：活动节点是否仍然存在、Xray 内核是否成功启动、路由模式是否仍为预期值。部分更新操作会改变服务器名称、传输参数或默认路由；列表中有节点不等于它已经被选为活动服务器。建议保留一条已验证的备用节点，但不要同时堆积大量重复配置，因为节点数量过多会增加测试时间和误选概率。
- 每周完成一次 Scholar 搜索、arXiv PDF 下载和 Overleaf 保存测试。
- 每次订阅更新后检查活动服务器、HTTP 端口和系统代理状态。
- 每次更换网络后重新确认 DNS、局域网直连和机构入口是否符合预期。
- 发现单一站点异常时，先查看日志中的最终域名，不要立即扩大为全局代理。
- 使用完成后关闭不必要的系统代理，避免其他程序误用科研代理链路。
如果当前只是需要快速开始，可以先使用 v2rayN 的规则模式完成浏览器验证，再逐步加入 Zotero 和 Overleaf 的应用测试。需要安装包或确认不同平台客户端的配置差异时，可前往安装包页面，并以当前页面提供的版本与说明为准。