V2Ray 安装配置手册

配置前检查

通用准备：先确定平台与配置来源

区分客户端、内核与服务器配置

桌面端优先选择 v2rayN，适用于 Windows、macOS 和 Linux；Android 优先选择采用 Xray 内核的 v2rayNG，需要 V2Fly 内核生态时再考虑 v2flyNG。图形客户端负责保存配置、更新订阅、生成运行参数和控制内核，真正处理连接的是内核进程。安装客户端不会自动获得可用服务器，也不会替用户创建订阅。开始前应准备合法取得、仍在有效期内的配置，并确认其适用的协议与传输组合。

服务器地址、端口、用户标识、传输方式和安全设置需要成套使用。不能看到协议名称相同，就把另一份配置的 TLS、路径或服务器名称拼进去。尤其是 VLESS、Trojan 等配置，认证字段与外层安全参数各有职责，遗漏其中一项也可能表现为连接超时。遇到无法导入的链接，先判断它是单个服务器分享链接、订阅地址，还是完整配置文件，再选对应入口，而不是反复粘贴到同一个文本框。

确认设备架构、时间与网络基线

下载前先查看系统信息。Windows 查看“系统类型”，macOS 查看“关于本机”中的芯片，Linux 同时确认处理器架构与发行版软件包类型。Android 多数较新的设备使用 arm64，但判断仍以设备实际支持的 ABI 为准，不能仅凭购买年份。安装包格式与处理器架构是两个维度：deb 与 rpm 决定包管理方式，x64 与 arm64 决定可执行程序能否运行。下载入口中的标注应同时匹配这两项。

启用系统自动校时，并确认时区设置合理。错误的系统时间会干扰证书有效期判断，也可能影响依赖时间的认证。随后在关闭代理的状态下打开常用网站，记录本地网络是否正常；若基础网络本身不可用，应先处理无线连接、网关或网络登录页。测试期间暂时退出其他代理和 VPN 工具，避免同一套系统设置被反复覆盖。企业设备还可能有管理员下发的代理策略，这种策略不能靠反复切换按钮解决。

建立可回退的初始状态

第一次运行只导入一组配置，只选一台服务器，先使用客户端已有的基础路由。不要同时打开 TUN、自定义 DNS、远程规则和多个实验选项。每完成一项调整就重试同一个测试目标，并记下修改前后的差异。这样可以把故障限制在刚改动的层级。正式调整前保存现有设置或截图，但截图应遮住订阅地址、用户标识与认证字段；这些内容即使看起来只是链接，也可能代表账户访问权限。

最后确定验证标准：浏览器能否加载目标页面、客户端是否有对应连接记录、直连站点是否仍能访问。单独一次延迟测试成功，只说明特定探测过程有响应，并不代表网页、DNS 或所有应用都已配置完成。后文各平台都按“安装、导入、接管、验证”的顺序展开，读者可以直接跳到自己的平台，但不要省略这一轮基线检查。

桌面端 / Windows

Windows：v2rayN 安装与系统代理

选择桌面版或经典 WPF 版

前往Windows 下载入口选择 v2rayN。桌面版采用新一代跨平台界面，经典 WPF 版沿用 Windows 桌面界面；两者应按使用习惯和实际兼容性选择，不要同时运行来比较连接效果。下载页当前提供的 x64 安装入口适用于相应系统架构。运行前阅读安装程序提示，若系统缺少运行组件，应按客户端或安装器说明补齐，不要从不明来源下载同名动态链接文件覆盖程序。

安装后先以普通用户权限启动。主窗口能够打开，并不等于内核已经启动；应在日志区域确认配置加载和本地入站监听情况。程序目录与用户数据目录可能分开保存，更新或迁移前先使用客户端支持的导出方式保留配置。不要把程序放在临时解压目录后随手清理，也不要在程序运行时移动整个目录，否则下次启动可能找不到内核、规则文件或已保存的设置。

导入订阅并指定活动服务器

打开订阅分组或订阅管理入口，新增一个容易辨认的分组名称，把完整订阅地址放进地址字段并保存，然后执行更新。若只是单个分享链接，应使用从剪贴板导入等对应功能，不必强行创建订阅分组。更新后检查列表是否出现预期配置，再通过双击或设为活动服务器的菜单指定一项。列表中存在服务器与服务器正在被使用是两回事，应以活动标记和内核运行状态共同确认。

订阅更新失败时，先看日志是解析失败、认证失败还是请求超时。初次连接尚未建立时，选择经代理更新可能形成循环依赖；此时应尝试直连更新，或使用配置提供方允许的其他获取方式。不要为了让列表出现内容而关闭所有安全检查。若更新成功但列表为空，检查分组过滤、账户有效性和返回内容格式，也应确认订阅地址没有在复制时混入换行或末尾标点。

从系统代理开始，再决定是否使用 TUN

选定服务器后，将系统代理设为“自动配置系统代理”或实际界面中含义相同的选项。它会让遵循 Windows 系统代理设置的应用使用本地代理入口，但不会接管所有网络程序。浏览器还可能被扩展或独立代理配置覆盖；命令行工具也常常不读取系统代理。此时不要马上更换服务器，应先观察发起请求时客户端是否记录到连接，以确认请求究竟有没有进入本地入口。

在确实需要接管更多应用时再启用 TUN，并按程序提示授予必要权限。TUN 涉及虚拟网络接口、路由和 DNS，不是系统代理按钮的另一种外观。首次测试可以先关闭系统代理，只保留一种接管路径，验证后再按客户端建议使用组合设置。遇到驱动、虚拟网卡或路由错误，应记录日志并检查权限及其他 VPN 软件，不要通过关闭整个防火墙来代替定位。

验证与退出后的恢复

用浏览器访问一个明确需要代理的目标，再访问一个应当直连的目标，对照日志中的出站选择。若浏览器可用而终端不可用，查阅系统代理与终端分开排查，不要把应用差异归因于服务器。结束使用前先清除系统代理，再退出客户端。异常关机后若浏览器提示代理无法连接，应到 Windows 网络代理设置检查是否仍指向已停止的本地端口；恢复后再重新启动客户端测试。

桌面端 / macOS

macOS：芯片选择、权限与网络服务

按芯片安装 v2rayN

打开macOS 下载入口，Apple Silicon 设备选择 arm64，Intel 设备选择 x64。芯片信息可以在“关于本机”查看，不要只凭产品外观或机型名称判断。下载 DMG 后打开磁盘映像，按安装界面把应用放入“应用程序”目录，再从正式位置启动。直接在磁盘映像中长期运行，容易在推出映像、更新程序或重启后遇到路径与权限问题，也不利于后续维护。

首次启动可能受到系统安全策略限制。先核对应用来源与所选平台，再在系统设置的“隐私与安全性”中查看是否有对应的允许打开入口。受管理设备可能禁止用户自行放行，这时需要管理员处理。不要为了运行单个程序而关闭整机的安全机制，也不要批量删除不理解的系统属性。若提示程序架构不匹配，应返回下载页重新选择，而不是把所有启动错误都当成权限问题。

导入配置并检查内核状态

在 v2rayN 中建立订阅分组，保存地址并更新，随后把一个配置设为活动服务器。导入单条分享链接时使用剪贴板入口；导入完整文件时则先确认文件适用于当前客户端，不要把内核专用 JSON 当作订阅地址。配置出现后查看运行日志，确认内核没有立即退出。部分问题只影响后台进程，主窗口仍然能够操作，因此“界面能打开”不能作为安装完成的唯一依据。

先使用默认或基础路由进行一次连接测试，再逐项调整 DNS 和分流。更换内核前，确认所选协议及传输方式在目标内核中受到支持；同一配置的显示名称相同，并不保证生成的参数完全兼容。如果切换后出现未知字段或配置解析错误，恢复原内核并查看客户端生成配置的相关提示，不要在用户界面和手写配置之间反复覆盖，避免下一次保存又把修改还原。

系统代理与网络服务的对应关系

macOS 的代理设置与网络服务有关。启用系统代理后，应检查当前实际使用的是 Wi-Fi、有线网络还是其他服务；切换接口后如果只有部分应用恢复直连，可能是新网络服务没有对应设置。系统设置中的 HTTP、HTTPS 与 SOCKS 代理字段也各有含义，不能仅因地址都写着本机就互换端口。使用客户端自动设置时，先保留自动生成的结果，确认连接后再做必要的手工调整。

浏览器可以遵循系统代理，但也可能被扩展或应用自身的网络选项覆盖。终端程序通常需要自己的代理参数或环境变量，它们并不会因为菜单栏显示代理已开启就自动改变行为。切换网络后还应重新打开测试连接，因为既有连接可能继续沿用旧路径。验证时用同一个目标创建新请求，再查看日志，避免把页面缓存、已有连接或应用后台重试误认为当前设置已经生效。

TUN 授权、休眠与恢复

需要 TUN 时按客户端提示完成权限申请。创建虚拟接口和修改路由通常需要额外权限，具体方式以当前程序实现为准。启用后若全网断开，先关闭 TUN 恢复网络，再检查日志中的接口创建、路由写入和 DNS 错误。不要同时开启另一套 VPN 的全局接管来“补救”，两者可能竞争默认路由，反而让问题更难复现。工作设备上的安全软件也可能限制这类网络操作。

退出前清除系统代理，并观察浏览器能否恢复直连。若应用已退出但网页仍报告本地代理连接失败，到当前网络服务的代理设置中检查残留项。不要删除整个网络服务或重置所有网络配置作为第一步。保留订阅与路由设置，只恢复接管层，通常能把影响范围控制得更小；确认恢复后，再回到客户端重新启用一项功能进行验证。

桌面端 / Linux

Linux：软件包、桌面代理与运行权限

同时匹配架构和发行版格式

Linux 使用 v2rayN 桌面客户端，先在Linux 下载入口区分 deb 与 rpm，再选择 x64 或 arm64。Debian、Ubuntu 等发行版通常采用 deb，Fedora 等通常采用 rpm，但仍应以本机包管理系统为准。可以用下面的只读命令查看架构及系统标识：输出中的 x86_64通常对应 x64，aarch64通常对应 arm64。不要把文件扩展名改成另一种格式来尝试安装。

uname -m
cat /etc/os-release

下载完成后，可使用桌面软件安装器打开软件包，或按发行版文档使用包管理器安装。依赖缺失时让包管理器报告具体项目，再判断当前桌面环境与系统版本是否满足要求。不要把别的发行版系统库直接复制进系统目录。安装失败与客户端配置失败是两个阶段：前者需要先解决软件包、依赖和架构，后者才需要查看订阅与内核参数，混在一起处理容易产生更多变量。

先用普通用户启动与导入

安装后从应用菜单启动 v2rayN，以普通用户完成订阅分组、地址保存和更新。更新成功后选择一个活动服务器，再检查内核日志是否进入监听状态。若桌面图标没有打开主窗口，可以从桌面环境提供的应用日志入口查看错误；不要立刻以管理员身份运行整个界面。使用不同身份启动可能产生不同的数据目录和文件所有权，之后普通用户反而无法写入原来的配置。

如果曾经用高权限启动导致配置不可写，应先退出程序，识别实际数据目录，再按系统管理方法修复该目录的所有者，而不是对整个主目录递归放宽权限。订阅地址和导出的配置属于敏感数据，目录访问权应限制在需要使用的账户内。更新客户端时保留用户数据，更新完成后检查内核路径与规则资源是否仍能找到；图形程序更新成功不代表原来的外部路径一定继续有效。

理解桌面系统代理的作用范围

Linux 的系统代理并不是所有程序共享的统一开关。GNOME、KDE 等桌面环境有自己的代理设置，应用还可能只读取环境变量、独立配置文件或启动参数。v2rayN 成功修改桌面代理后，浏览器可能已经可用，而终端中的请求仍保持直连。这种现象先按应用层差异处理：确认请求有没有进入客户端，再决定是否需要设置单个工具，或改用能够覆盖更多流量的 TUN。

下面的命令通过本地 SOCKS 入口请求示例站点，适合检查“工具到本地代理”这一段。端口必须替换为客户端设置中实际监听的值；示例使用 socks5h，表示由代理端处理目标域名解析。测试成功只能证明这次请求经过了指定入口，不能推断桌面系统代理、其他终端或所有应用都已经生效。若提示连接被拒绝，先检查内核是否运行及端口是否一致。

curl --proxy socks5h://127.0.0.1:10808 --head https://example.com

TUN 权限与网络管理冲突

TUN 需要访问虚拟网络设备并管理相关路由。授权方式取决于客户端打包和系统策略，应优先使用程序提供的权限流程，不要随意给整个安装目录附加高权限。启用失败时分别检查虚拟设备是否可用、权限是否被拒绝、默认路由是否与其他 VPN 冲突。容器或受限桌面会话可能根本不具备所需设备与权限，不能仅靠反复点击开关解决，也不应为此放宽整机安全边界。

Linux 上还要注意系统解析服务与客户端 DNS 的边界。系统可能通过本地存根解析器处理查询，TUN 则可能接管另一条解析路径。出现仅域名失败的现象时，先比较系统解析与代理请求，不要同时修改网络管理器、解析服务和客户端三处配置。退出后确认桌面代理与临时环境变量已恢复；若只在某个终端异常，检查该终端的会话变量，而不是重装客户端。

移动端 / Android

Android：VPN 授权与后台运行

选择 v2rayNG 或 v2flyNG

Android 首推 v2rayNG，采用 Xray 内核；需要 V2Fly 内核生态时可选 v2flyNG。两款客户端在Android 下载入口分别提供 arm64 与通用安装包。多数较新的设备适合 arm64，但系统位数与设备支持情况仍应实际确认，无法判断时可考虑通用包。不要仅因为两款应用图形界面相近就认为配置功能完全一致，协议、传输与安全参数最终还取决于各自内核支持。

安装 APK 时，Android 可能要求为浏览器或文件管理器授予安装应用的权限。只对本次使用的来源按需授权，完成安装后可以撤销。若系统提示应用无法安装，先检查设备架构、剩余空间和现有应用签名冲突；覆盖安装失败不一定是包损坏。准备卸载重装前先通过客户端功能备份必要设置，卸载可能清除分组、路由和应用选择，不能假设重装后会自动恢复。

订阅导入与首次 VPN 授权

打开订阅设置，新增分组并填入完整地址，保存后回到列表更新订阅，再点选需要使用的服务器。单条分享链接可从剪贴板或二维码入口导入，但二维码本身也可能包含账户信息，不宜转发到公开平台。导入后核对协议及必要字段，不要只看备注名称。若列表内有多个分组，确认当前筛选没有把刚导入的配置隐藏；更新完成也不会自动保证活动服务器已经切换。

点击连接后，系统会显示 VPN 连接授权，确认后客户端才能通过 Android 的 VpnService 接管流量。这里的 VPN 标志表示系统已经建立相关接口，并不表示远端服务器完成认证或网页一定能打开。应再查看客户端日志，并实际访问测试目标。普通应用通常只能有一条活动的系统 VPN 通道，其他 VPN、广告过滤或网络防护应用可能占用它；应先明确保留哪一个，再重试连接。

路由、分应用与本地代理入口

先用客户端基础路由连接，再按需要设置分应用代理。不同界面对“代理所选应用”与“绕过所选应用”的表达可能相反，保存前必须看清当前模式。选择浏览器时还要考虑页面是否会调用外部应用、下载管理器或系统服务，它们不一定与浏览器共用同一身份。排查某个应用时，可以先暂时恢复较宽的接管范围；若恢复后可用，再逐项缩小范围定位遗漏项。

Android 的 VPN 接管与桌面的系统 HTTP 代理不同，一般不需要在 Wi-Fi 高级设置中再填写本地代理。额外写入 Wi-Fi 代理反而可能在客户端停止后导致网络异常。客户端显示的本地 SOCKS 端口主要面向需要显式代理的程序，不代表局域网其他设备默认可访问。不要为方便测试就把监听地址改成所有接口；跨设备共享会引入访问控制、网络隔离和权限方面的新问题。

电池管理、网络切换与断连恢复

若前台正常、锁屏一段时间后断开，优先检查电池优化和后台活动限制。不同系统厂商的入口不同，可以在应用信息中允许必要的后台运行，并按需要保留前台通知。把应用加入省电例外只是在降低被后台清理的概率，不会修复错误的服务器或 DNS。连接日志若在息屏时停止、重新打开应用才恢复，才更符合后台管理影响的特征，应与持续出现握手错误的情况区分。

在移动数据和 Wi-Fi 之间切换后，先确认基础网络已完成登录，再重新建立连接。某些网络对 UDP、域名解析或目标端口的处理不同，不能用单一网络上的结果概括服务器状态。若只有后台断连，继续阅读v2rayNG 电池优化与分应用设置；若两个网络都无法加载页面，则按文末的日志分层方法检查，而不是持续重装应用。

跨平台 / 配置生命周期

订阅管理：更新、选择与备份

把订阅地址与分享链接分开

订阅地址通常通过一次网络请求返回一组服务器配置，单条分享链接则直接描述某个服务器。两者可能都能复制到剪贴板，但处理方式不同：订阅应保存在分组中以便更新，分享链接则通过对应导入入口解析。网页地址也不一定就是订阅地址，账户管理页、说明页或登录跳转页不能直接当作配置来源。更新后若日志提示解析失败，应先向配置提供方确认地址用途和返回格式。

订阅地址往往包含访问凭据，能够获取配置的人可能获得同一账户资源。因此不要把完整地址粘贴到公开反馈、在线解析站点或截图中。需要描述问题时，只保留错误类型、客户端名称和必要的非敏感参数。二维码、导出文件和备份目录也按同样原则处理。若地址已经泄露，应在配置提供方支持的管理入口重新生成或撤销旧地址，仅删除本地历史记录不能让外部副本失效。

区分更新通道与实际使用通道

直连更新与经代理更新决定的是订阅请求通过哪条路径获取，并不等于服务器的路由模式。初始状态还没有可用服务器时，经代理更新可能无法启动；已有连接可用而直连访问订阅失败时，才可能需要经代理更新。选择时应观察请求超时、认证拒绝和内容解析三种不同结果。对明确返回认证错误的请求，切换更新通道通常不会解决问题，应先检查账户权限和地址有效性。

更新失败后不要立即清空原有列表。先保留仍可能可用的配置，记录分组和错误信息，再确认当前网络是否可访问订阅服务。有些客户端会保留旧配置，有些更新操作可能重建分组内条目，具体行为应从界面提示与实际结果判断。手工编辑订阅生成的条目时尤其要谨慎，下一次更新可能覆盖修改。长期需要自定义参数的配置，宜通过客户端支持的复制或独立管理方式保存。

更新成功后仍需检查活动项

订阅更新成功只说明获取与解析过程完成，不保证当前活动服务器仍存在，也不保证它的网络可达性。更新后检查活动标记、协议类型和分组筛选，再发起实际请求。备注名称可能重复或变化，不能只凭名称判断还是同一配置。某些条目的端口、传输路径或安全参数可能随订阅一起改变，因此排查更新后故障时，应优先确认客户端是否重新加载了新的运行配置。

延迟测试、连通性测试与真实网页加载并不等价。测试目标、解析方式和探测协议不同，结果就可能不同；某台服务器在探测中有响应，仍可能无法访问特定站点。不要把列表排序后的第一项当成所有场景的最优解。更可靠的做法是选择一项配置，用固定目标验证页面加载、域名解析与直连例外，再根据真实使用情况决定是否保留，而不是依赖单个测试数字。

备份与迁移要包含设置边界

迁移设备时，优先导出客户端支持的配置与设置，不要直接覆盖另一平台的整个程序目录。订阅地址可以重新导入，但本地端口、路由规则、分应用选择和系统接管权限未必随之迁移。特别是 Android 的应用列表与桌面的应用路径没有直接对应关系，跨平台恢复后应重新检查。备份文件应保存在受访问控制的位置，不能因为是个人笔记就把完整认证信息放进公开同步内容。

需要比较客户端的订阅与内核能力时，可查阅客户端对比。不要用同时安装更多客户端代替检查来源和格式；只要订阅本身返回错误内容，更换图形界面通常仍会遇到同一类问题。

跨平台 / 流量路径

路由与 DNS：先接管，再决定出站

系统代理、TUN 与内核路由各管一层

先判断请求是否进入客户端，再讨论分流。系统代理让遵循系统设置的应用主动连接本地入口，TUN 则通过虚拟网络接口接管适用流量；进入内核后，路由规则才决定使用代理、直连或其他已定义出站。应用绕过系统代理时，修改内核规则不会产生效果。反过来，请求已经进入内核却被规则分到直连，也不应继续排查浏览器代理按钮。日志是划分这两种情况的重要依据。

“全局”与“规则”在不同客户端中可能出现在不同层级。系统代理的全局设置通常只是让更多请求送入本地代理，而内核仍可能按规则选择出站；某些客户端的全局路由模式才会改变内核分流。因此应看清当前修改的是系统接管方式还是内核路由模式。测试时先固定接管方式，再对比路由变化，避免同时更改两层之后无法判断是哪一项让请求恢复或失败。

用最小规则理解匹配顺序

下面是 Xray 风格的局部路由示例，只演示将示例域名交给名为 direct的出站。它不是完整可启动配置，使用前必须在完整配置中定义同名出站；实际客户端可能自动生成其他标签，应按生成结果调整。路由通常按规则顺序寻找匹配项，前面较宽的规则可能先于后面精确规则命中。维护例外时先检查已有规则，而不是不断向末尾追加重复条件。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

精确域名与域名后缀的范围不同。只为主域名写规则，不一定涵盖页面所需的图片、认证或接口域名。遇到页面主体加载但登录失败时，应查看失败请求对应的域名和出站，不要直接把整个网络改成另一种模式。地址规则也有类似边界：IPv4 与 IPv6 是不同地址族，只处理其中一种，不能保证另一个协议栈的请求也按预期分流。

分清系统解析与内核解析

DNS 决定域名如何得到地址，但系统、浏览器和代理内核可能各自有解析路径。浏览器启用自己的安全 DNS 后，结果未必来自系统解析器；应用向 SOCKS 入口发送域名或已经解析好的 IP，也会影响内核还能使用哪些域名条件。排查时先确认域名在哪一层解析、查询通过哪条出站发送，再决定修改哪一处。盲目同时更换全部 DNS，只会让原本可定位的问题变成多个变量。

下面的片段展示内核 DNS 服务器数组和查询地址族设置，属于局部示例。服务器能否访问仍取决于当前网络、路由和客户端生成配置，不能把某个公共解析地址当成所有网络下都合适的固定答案。加密 DNS 的端点如果需要域名解析，还要考虑启动时如何取得该端点地址，避免解析请求依赖尚未建立的代理连接，形成相互等待。

{
  "dns": {
    "servers": ["1.1.1.1", "8.8.8.8"],
    "queryStrategy": "UseIP"
  }
}

检查局域网、IPv6 与 UDP 边界

TUN 启用后若打印机、局域网服务或本地管理页面不可访问，应检查私有地址和本机服务是否有适当的绕过规则。不要为解决一个局域网地址的问题把所有流量都设为直连。IPv6 环境中还要观察应用实际选用的地址族；只用 IPv4 测试成功，不能证明双栈请求完整可用。对于语音、游戏或其他 UDP 应用，则需同时确认协议、服务器和接管方式支持相应流量。

完成调整后重载内核，并用新连接验证。已有连接可能继续使用之前的出站，应用缓存也可能保留旧解析结果。只刷新同一个页面而不观察连接日志，容易把缓存造成的差异误判为规则失效。

配置常见问题 / 按层排查

配置排查：从本地入口到远端连接

先记录现象，避免同时重置所有设置

开始排查时记录客户端名称、操作系统、所用内核、接管方式和失败目标，并说明是所有应用失败，还是只有某个浏览器或终端失败。再记录最近一次成功后改过什么：订阅更新、网络切换、系统升级或路由调整。不要把这些步骤压缩成一句“已连接但不能用”。越具体的现象越容易定位，也能避免在本地端口尚未监听时反复更换远端服务器，或在账户失效时持续修改 DNS。

先关闭 TUN 和系统代理，确认基础网络可用；随后只恢复一种接管方式。若关闭后仍然无法联网，检查系统是否保留本地代理地址、Android 是否启用了阻止非 VPN 流量，或者网络是否需要登录。只有直连基线恢复，后续对比才有意义。恢复设置时保留订阅和已有规则备份，不要把删除所有数据当成默认操作，否则有可能丢失仍可用于对照的有效配置。

按日志划分失败位置

日志出现监听端口占用时，应先退出重复运行的客户端或其他占用同一端口的程序，再决定是否修改本地端口。若修改了端口，浏览器扩展、终端参数和其他显式代理也要同步。连接被拒绝常见于目标入口没有监听，连接超时则只说明规定时间内未完成连接，不能仅凭这个词判断是 DNS、网络还是服务端。配置解析错误更应优先检查字段与内核兼容性，而非调整系统代理。

请求没有出现在日志中，优先检查应用到客户端的路径：系统代理是否生效、浏览器扩展是否覆盖、分应用列表是否遗漏。请求已出现但握手失败，则检查服务器地址、端口、认证、传输与安全参数是否成套，以及系统时间是否正确。请求已经按预期出站但只有某个网站异常，再检查该网站的解析、证书和网络响应。不要因为一个目标失败就认定整套客户端没有运行。

常见问题的处理边界

提交问题时保留必要证据

需要进一步求助时，提供可以复现的操作顺序、失败时间附近的日志和已经验证过的分支。遮住完整订阅地址、用户标识、密码和其他认证字段，仅保留判断故障所需的信息。日志级别提高后可能包含更多访问目标，记录完应恢复合适级别。不要在公开反馈中直接上传整个配置目录，也不要用包含账户凭据的截图代替文字描述。

如果仍然显示连接正常却无法打开网页，继续按连接后无法上网的逐项检查清单核对。若只是想重新走一次最短配置路径，返回快速上手即可；需要更换平台安装包时进入下载页。保留一个已知可用的最小配置，通常比持续叠加规则、切换内核和重装程序更有助于定位下一次故障。