v2rayN 导入订阅后无法连接？按节点、核心和系统代理排查
简答：v2rayN 导入订阅后无法连接，先确认订阅更新成功并选中活动节点，再启动核心、开启系统代理，用全局模式测试。若仍失败，根据 guiLogs 和主界面核心日志定位是订阅、节点、核心还是本地代理问题，通常可以在不重装的情况下确认故障层级。
定义：“v2rayN 导入订阅后无法连接”是指订阅或节点已出现在客户端中，但核心无法建立连接，或核心已启动却没有流量经过本地代理。
先做这组快速判断：不要一开始就重装
本文只处理 v2rayN 桌面端导入订阅后的连接故障。本站是第三方使用指南站，不是 AmyTelecom 官方；如果订阅来自某个服务，请以该服务提供的订阅信息和官方说明为准。
| 现象 | 优先检查 | 下一步 |
|---|---|---|
| 订阅更新失败，列表没有新节点 | 订阅地址、返回内容、更新日志 | 先确认地址完整且没有返回登录页或 HTML，再重新更新订阅 |
| 节点列表为空或导入后没有可用配置 | 订阅格式和解析结果 | 查看更新提示；如果提示解码或解析失败，不要继续测试节点 |
| 只有一个节点超时 | 该节点参数或节点状态 | 切换同一订阅中的其他节点，避免马上修改核心和 DNS |
| 全部节点超时或拒绝连接 | 核心、系统时间、本地端口和网络环境 | 查看主界面核心日志，确认核心是否真正启动 |
| 延迟测试成功但网页打不开 | 活动节点、系统代理、浏览器代理 | 先开启系统代理，再用全局模式访问测试页面 |
最短修复路径：更新订阅 → 确认节点出现 → 选中一个活动节点 → 启动核心 → 开启“自动配置系统代理” → 暂时使用全局模式测试。官方项目说明中，系统代理负责把部分应用流量转给核心，而路由模式决定流量如何分流；因此延迟测试成功并不等于浏览器已经走代理。
参考 v2rayN 官方系统代理和路由说明 与 v2rayN 官方 FAQ。
第一步：确认订阅是真的更新成功
- 打开 v2rayN 的订阅分组设置，检查订阅地址是否完整。不要只看分组名称或旧节点还在不在，重点看本次更新是否出现成功、解码失败或解析失败提示。
- 执行一次订阅更新，等待更新过程结束。更新后确认节点数量是否发生变化，并检查活动节点是否仍然存在。官方代码显示，客户端会先下载订阅内容，再处理解码和批量导入；下载为空或解析数量为零时，更新不会形成可用节点。
- 如果更新失败，用 PowerShell 执行带 User-Agent 的 GET 请求检查返回内容。请在 PowerShell 中执行；不要把完整订阅地址、Cookie 或 token 粘贴到公开日志中。
$u = "订阅地址"; Invoke-WebRequest -Method Get -Uri $u -UserAgent "v2rayN" -UseBasicParsing - 检查返回结果是否像配置内容，而不是登录页面、错误页面或需要网页登录的 HTML。若状态正常但内容格式不被当前核心识别，优先回到订阅提供方确认格式，不要连续更换多个核心。
订阅地址本身包含访问凭证时，截图只保留域名和状态信息，隐藏完整 URL、查询参数、二维码和节点密码。关于订阅下载、解码和解析的处理流程，可查看 v2rayN 官方订阅处理代码。
第二步：确认节点、核心和本地端口都已工作
- 在节点列表中选中一个节点，并明确将它设为当前活动服务器。不要只运行延迟测试后就认为浏览器已经连接；延迟测试只代表测试目标在当时可达。
- 先不要开启 TUN。启动当前节点对应的核心，观察主界面信息栏是否出现核心启动失败、配置解析失败、端口占用或连接错误。
- 检查本地监听端口是否已经建立。如果核心启动后没有本地 HTTP 或 SOCKS 监听，优先处理配置解析、核心文件权限或端口冲突，不要先修改 DNS。
- 确认系统时间自动同步。对于使用 TLS 或 REALITY 的节点，本机时间异常、地址、端口、传输方式、SNI、指纹、公钥、shortId 或 flow 等参数不一致，都可能导致握手失败；这些字段不能凭感觉改写。
- 如果只有某个节点失败，换同一分组中的另一个节点；如果所有节点都失败，再检查核心版本、订阅转换结果、本地端口和当前网络。一次只改一类参数，便于从下一条日志判断变化来源。
v2rayN 官方文档将“订阅、节点、核心、系统代理和 TUN”视为不同层级；先建立一个能验证的最小连接，再增加路由、DNS 或 TUN 设置，更容易定位问题。可参考 官方 FAQ 和 官方界面参数说明。
第三步：延迟正常但网页打不开，检查系统代理
如果节点延迟测试有结果，但浏览器仍然打不开网页，常见原因是测试请求成功了，而浏览器流量没有进入 v2rayN。按以下顺序处理：
- 确认核心正在运行，并且已经选中活动节点。
- 在 v2rayN 底部或托盘菜单中选择“自动配置系统代理”。官方说明中，这个模式会把操作系统的代理设置指向核心入口；“不改变系统代理”不会替你接管代理。
- 暂时将路由模式切换为“全局”进行验证。全局模式只用于定位问题，确认网页可访问后，再切回合适的规则模式。
- 检查浏览器是否设置了独立代理、代理扩展或 PAC。浏览器自己的代理设置可能覆盖系统代理；先关闭扩展和独立代理，再重新打开一个浏览器窗口测试。
- 若其他应用仍不能连接，不要据此判断节点失效。部分命令行工具、开发工具和应用可能不读取系统代理，需要单独设置代理，或在确认普通系统代理可用后再考虑 TUN。
不要同时开启 TUN、修改 DNS、替换核心和切换路由。先用系统代理完成最小验证，再处理更复杂的流量接管问题。
第四步：按日志关键词决定修复动作
| 日志或现象 | 通常说明 | 处理动作 |
|---|---|---|
connection refused | 目标端口拒绝连接，或本地监听端口没有对应服务 | 先换节点；若所有节点都出现，再检查核心是否启动和本地端口是否被占用 |
i/o timeout 或持续 timeout | 连接在规定时间内没有完成 | 检查当前网络、节点可达性和系统时间，换两个节点交叉测试 |
TLS handshake timeout | TLS 握手阶段超时 | 核对地址、端口、SNI、传输和安全参数，不要只修改浏览器代理 |
| 核心启动失败或配置解析失败 | 配置内容、核心版本或文件状态存在问题 | 查看主界面核心日志，重新选择节点并检查对应核心文件 |
| 延迟有结果但没有网页请求 | 浏览器流量没有进入 v2rayN | 开启“自动配置系统代理”，关闭浏览器独立代理后重新测试 |
v2rayN 的日志位置需要分开看：界面操作、设置和测速等客户端问题通常记录在 guiLogs 文件夹；核心问题则显示在主界面信息栏中。复现问题前先清理旧日志，重新执行一次失败操作，再保存最新日志。提交截图或日志时，删除订阅地址、token、Cookie、用户 ID 和完整节点链接。具体位置和分类见 v2rayN 官方 FAQ 的日志说明。
最后核对：什么时候才需要检查 TUN、DNS 或重新导入
只有在“订阅更新成功、节点已选中、核心能启动、系统代理已验证”之后，才建议进入下一层：
- TUN：当某个应用不读取系统代理时再考虑。TUN 涉及虚拟网卡、权限、路由和软件冲突，排障时先关闭 TUN，确认普通系统代理可用，再单独开启测试。
- DNS：如果日志显示域名解析失败、浏览器提示 DNS 错误，才进入 DNS 排查。不要把 DNS 修改作为所有超时问题的第一步。
- 重新导入：只有当订阅返回内容正常、节点列表明显损坏或更新后的配置解析失败时，才备份现有分组后重新导入。重复添加同一个订阅地址会增加排查干扰。
- 更换核心：如果多个节点都在核心启动阶段失败，检查当前节点使用的核心类型和对应文件；不要把 Xray 与 sing-box 的配置字段混用。
排查完成后的判断标准是：订阅更新有明确成功结果、至少一个节点能启动核心、系统代理能让浏览器产生请求，并且日志不再出现新的连接或握手错误。
常见问题
为什么 v2rayN 能测出延迟，网页却打不开？
延迟测试只验证特定测试目标和当前节点的某个连接结果，不代表浏览器流量已经经过系统代理。请先选中活动节点，启动核心，选择“自动配置系统代理”，并暂时用全局模式测试。
订阅导入后节点还在，但更新失败，需要重新导入吗？
不一定。先看更新日志和返回内容；如果旧节点仍在，说明本地列表未必丢失。检查订阅地址是否过期、是否返回登录页或 HTML，再决定是否重新导入。
v2rayN 核心启动失败，应该先改 DNS 吗？
不建议。核心启动失败通常应先看主界面核心日志、配置解析提示、核心文件和本地端口占用。DNS 主要用于处理域名解析类问题，不能替代核心启动排查。
全部节点都连接超时，怎样判断是本地问题还是节点问题？
先确认订阅更新成功，再测试同一分组中的多个节点；同时检查系统时间、核心是否启动、当前网络是否能访问订阅地址。如果多个节点都失败且核心日志一致，再继续检查本地端口、核心版本和网络环境。
排查时可以直接开启 TUN 吗？
不建议作为第一步。先用普通系统代理完成单节点验证，因为 TUN 会增加虚拟网卡、权限和路由变量。确认基础连接正常后，再为不读取系统代理的应用单独测试 TUN。
常见问题
为什么 v2rayN 能测出延迟，网页却打不开？
延迟测试不等于浏览器流量已经经过系统代理。请确认活动节点、核心和自动配置系统代理均已启用，并暂时使用全局模式验证。
订阅导入后节点还在，但更新失败，需要重新导入吗？
不一定。先检查更新提示和订阅返回内容，确认不是过期地址、登录页或 HTML，再决定是否重新导入。
v2rayN 核心启动失败，应该先改 DNS 吗？
不建议。先查看主界面核心日志，检查配置解析、核心文件和本地端口；DNS 只应在出现域名解析类错误时排查。
全部节点都连接超时，怎样判断是本地问题还是节点问题？
测试同一分组中的多个节点，并同时确认订阅更新、系统时间、核心启动和本地端口状态。多个节点出现同类日志后，再继续检查本地网络和核心。
排查时可以直接开启 TUN 吗？
不建议作为第一步。先用普通系统代理完成单节点验证，基础连接正常后，再为不读取系统代理的应用单独测试 TUN。