v2rayN 完整手册
从核心概念到日常维护

阶段一 · 建立概念

核心概念与连接链路

区分客户端、内核和远端服务

先把一次连接拆开看：应用发出请求，经本机代理入口进入内核，再由路由规则决定直连或交给远端服务器。v2rayN 是管理这些设置的图形客户端，负责保存服务器资料、更新订阅、选择活动配置并启动内核。内核负责实际处理协议与连接。下载客户端并不等于获得远端服务，服务器地址、身份参数和有效期限需要从已有的合法服务来源取得。

Project V 是理解这一生态的起点，V2Fly 与 Xray 是相关内核家族。客户端界面与内核能力不是一回事：界面能显示某个字段，不代表当前使用的内核一定支持该组合。导入后若提示不支持协议、传输或安全设置，先确认实际调用的内核，再核对配置。不要把缺少支持误判为订阅失效，也不要看到客户端启动就认定远端已经连通。

按字段理解协议与传输

VMess、VLESS、Trojan 属于连接配置中的协议层信息；TCP、WebSocket、gRPC 等描述承载方式；TLS、REALITY 等涉及安全握手或相关机制。它们不是随意替换的性能选项。远端要求什么，本地就需要保留什么，包含地址、端口、用户标识、服务名、路径与服务器名称等。VLESS 协议本身不等于加密通道，是否具备相应保护要看完整传输与安全配置。

域名字段也不一定承担同一个作用。服务器地址决定先连接哪里，TLS 的服务器名称参与证书与握手处理，WebSocket 的 Host 则属于请求头。三个值可能相同，也可能不同。地址能解析，只能说明解析环节得到结果；端口能建立连接，也不能证明身份认证通过。排错时应沿着解析、网络连接、安全握手、协议认证、目标访问逐层观察，而不是把所有失败都归为网速问题。

建立可重复的验证基线

准备一个日常可直连的网站和一个确实需要代理的测试目标，关闭其他网络接管工具，记录当前活动服务器、系统代理状态与路由预设。测试时使用同一浏览器和同一网络，只改一项设置，再观察日志与访问结果。若只凭某个页面偶尔打开来判断，缓存、连接复用和应用自带解析都可能干扰结论。切换配置后，新建连接往往比反复刷新同一页面更容易看清变化。

理解测试结果的边界。列表中的延迟结果只能反映对应测试方法，不能直接代表下载带宽；网页请求成功，也不能推断实时通信、游戏或所有 UDP 流量都正常。记录失败发生在哪一层、哪类应用和哪个目标，比记录一句“无法连接”更有用。后续每章都沿用这条基线：先证明上一层成立，再增加下一层能力，出现异常就回到最近一个可工作的状态。

阶段二 · 确定工具

客户端与平台选择

桌面端优先选择 v2rayN

在 Windows、macOS、Linux 上先考虑 v2rayN，把订阅、服务器列表和路由管理集中在同一套操作逻辑中。进入下载页前，先确认操作系统与处理器架构。系统名称相同不代表安装包通用，尤其是 ARM 与 x64 之间不能只看文件图标判断。需要逐项比较时，可先阅读选型指南，再回到下载页选择对应入口。

Windows 提供桌面版 Desktop 与经典 WPF 版。前者采用新一代跨平台界面，后者保留经典 Windows 界面的操作习惯。初次使用可从桌面版开始；已有稳定工作流程时，先了解两版的界面与配置差异，再决定是否迁移。不要把两种界面当成两个服务来源，也不要为了排错同时启动两份客户端，否则本地端口、系统代理与配置目录容易互相干扰。

按系统信息选择架构

在 Windows 的“设置 → 系统 → 系统信息”查看系统类型，不要仅凭电脑品牌判断。macOS 打开“关于本机”，显示 Apple 芯片时选择 Apple Silicon 对应入口，显示 Intel 时选择 Intel 入口。Linux 除了区分处理器，还要确认发行版采用 deb 还是 rpm 软件包管理。包格式与桌面环境并非一一对应，不能因为使用相同桌面就照搬另一台机器的安装选择。

Android 首选 v2rayNG，使用 Xray 内核；需要与 V2Fly 内核行为保持一致时，再考虑 v2flyNG。较新的主流手机通常适合 arm64，不能确认架构时可考虑通用版，但仍要检查系统要求。通用版不表示自动支持所有协议组合，它主要解决打包架构覆盖问题。两款应用的设置可相似，但特性支持不能简单画等号，具体差异可查阅Xray 与 V2Fly 内核对比。

选择依据先于性能猜测

先列出必需条件：远端协议能否支持、订阅格式能否导入、目标应用是否需要 TUN、设备是否允许提升权限。满足这些条件后，再比较界面习惯与日常维护成本。客户端无法凭空改善远端线路质量，换界面也不能解决服务过期或参数错误。对同一配置进行比较时，尽量保持网络、目标站点和测试时间接近，避免把线路波动误认为客户端差异。

迁移时保留原有可用方案，但不要同时接管网络。先备份订阅来源和必要的自定义规则，在新客户端中单独验证导入、选择服务器、访问目标这三件事，再迁移复杂分流。手机与电脑可以使用同一服务来源，但仍需遵守服务方的设备数量与并发约束。选型结束的标志不是安装了更多应用，而是确定一个主用客户端、一条恢复路径和一份可以说明来源的配置。

阶段三 · 完成初始化

安装、权限与首次启动

准备稳定的运行位置

先从下载页的对应平台入口选择安装包，再按系统提示完成安装。安装程序与解压运行的程序管理方式不同：若拿到的是压缩包，应完整解压到长期保留的目录，不要只从压缩软件中打开主程序。首次启动会生成配置、日志等数据，目录需要可写。不要把运行目录放在临时清理位置，也尽量避免被同步软件同时改写。

Windows 首次启动若提示缺少运行环境，按错误信息确认所需组件与架构，不要从不明弹窗下载所谓修复工具。安装受组织策略管理的设备时，先确认是否允许运行代理软件与创建虚拟网卡。普通系统代理通常不要求持续以管理员身份运行，TUN 则可能涉及额外权限。把普通启动与提升权限启动分开验证，能更快区分程序故障、目录权限和网络驱动问题。

按平台处理启动阻碍

macOS 安装后，将应用放到稳定的应用目录再运行；遇到安全提示，先确认下载来源和系统兼容性，再通过系统提供的安全设置处理，不要直接复制关闭系统保护的命令。Linux 使用发行版的软件包安装工具处理依赖，若启动失败，先读取缺少的库或运行环境提示。图形界面能显示并不代表网络权限已满足，涉及虚拟网卡时仍需单独检查系统授权方式。

Android 安装 v2rayNG 或 v2flyNG 后，首次启动连接可能弹出系统 VPN 授权。这是本机流量进入应用处理的系统入口，不代表已经获得远端服务。先阅读授权内容，再允许已确认来源的客户端。暂时不要同时开启其他使用相同入口的应用。后台限制可能在锁屏后中断连接，等基础连接正常后，再按设备系统的电池设置为客户端调整后台运行权限。

检查本机监听与界面状态

进入 v2rayN 主窗口，先找到服务器列表、订阅分组、日志和底部状态栏。列表为空是尚未导入配置时的正常状态，不需要立即修改内核参数。打开“设置 → 参数设置”，查看实际的本地监听设置，并记录端口与监听地址。不同配置可能使用不同入口，后续应用手动填写代理时应以这里显示的实际值为准，不要凭教程中的常见数字猜测。

若日志出现地址已被占用，先退出其他客户端，再检查是否存在未结束的旧进程。不要连续随机改端口，因为浏览器或其他应用可能仍指向原端口，造成第二个问题。监听地址通常应保持本机范围；只有明确需要局域网共享时才考虑扩大监听，并同时设置访问控制与防火墙。把本机端口开放到网络不是解决本机连接失败的常规步骤。

首次启动的验收只看三点：界面能稳定打开，配置可以保存，内核启动没有持续报错。此时还不要求所有网站都可访问，因为远端资料尚未完成。建议先阅读主界面详解熟悉日志入口，再进入订阅章节。发生安装异常时保留原始错误文字与系统架构信息，先处理明确的环境错误，避免用重装系统替代定位。

阶段四 · 导入配置

订阅导入与服务器管理

分清订阅地址与分享链接

先判断手里的资料是什么。订阅地址通常是一个用于拉取服务器列表的 URL；以 vmess://、vless:// 等开头的内容通常是单条分享链接；完整 JSON 则可能是一份内核配置。这三类资料不能只凭“都是一段文本”混用。普通订阅更新入口不一定接受完整配置文件，分享链接也不应被当成网页地址放入订阅 URL 字段。

订阅地址可能携带可直接使用服务的凭据，应像账号资料一样保存。不要把完整链接贴进公开截图、论坛或测速求助帖，也不要提交给陌生的在线格式转换页面。若使用脱敏记录，保留协议类型、错误类别与必要字段名即可。服务方提供新的订阅地址时，先确认旧地址是否失效，再替换来源，避免留下多个指向同一服务的重复分组。

按分组完成导入与更新

1. 打开“订阅分组 → 订阅分组设置”，新增一个能识别来源的别名。
2. 把完整订阅地址填入“可选地址(URL)”，检查首尾空格、换行和复制截断。
3. 确认“启用更新”状态后保存，再从“订阅分组”菜单执行更新当前订阅。
4. 回到对应分组，检查列表与日志，再选择一个服务器设为活动服务器。

首次更新时先使用不经当前代理的更新方式，前提是订阅地址能够直连。如果地址必须通过代理访问，需要先有一条独立可用的连接，再选择菜单中的通过代理更新方式。不要让一份尚未导入成功的订阅承担下载自身的任务。更新返回错误时，先看是解析失败、请求超时、认证拒绝还是内容无法识别，不要把这些不同原因都处理成删除重建。

订阅分组 → 订阅分组设置 → 可选地址(URL) → 保存 → 更新当前订阅

理解更新对本地修改的影响

订阅是来源的同步结果，不是适合长期手工修改的唯一副本。服务方更新后，服务器别名、地址甚至条目顺序都可能变化，本地对订阅条目的修改也可能被覆盖。需要试验参数时，先复制成独立条目并注明用途，不要直接改动主用来源。自动更新间隔应按实际需要设置，频繁请求不会让远端凭空增加线路，还可能触发来源端的访问限制。

列表为空时，先确认当前选中的分组以及界面筛选条件，再查看更新日志。返回登录页面或提示页面，不等于拿到了可解析的订阅；服务过期、访问限制和格式不兼容都可能表现为导入失败。若只有某个协议条目缺失，应核对客户端与内核支持，而不是立即更换全部配置。订阅格式的区别和转换边界可继续阅读订阅格式说明。

更新成功后不要立刻批量删除旧条目。先选定一个新条目，完成实际访问，再确认原活动服务器是否仍存在。为常用分组保留清晰名称，记录服务期限与更新方式，但不要把凭据写进别名。做到来源可辨、活动项明确、更新结果可查，后续切换代理模式时才有稳定基础。需要只看操作步骤时，可返回订阅导入快速步骤。

阶段五 · 接入应用

系统代理与全局代理

先建立普通应用的代理入口

选择一个活动服务器后，在 v2rayN 底部系统代理选项中选择“自动配置系统代理”。这个操作会设置操作系统供应用读取的代理入口，但不会强迫所有进程遵守。部分浏览器遵循系统设置，部分应用使用独立设置，还有一些连接方式根本不读取系统代理。先用遵循系统设置的浏览器验证，再处理特殊应用，比一开始就判断整台电脑全部接管更可靠。

“清除系统代理”用于移除相应系统代理配置，适合退出前恢复直连或排查入口问题。“不改变系统代理”表示客户端不主动调整该设置，不等于当前系统一定没有代理。若此前残留了手动配置，选择不改变仍可能继续指向旧端口。退出后网络异常时，先进入系统代理设置核对地址与端口，再决定是否清除，不要在客户端已经关闭时继续让应用连接失效入口。

不要把全局路由当成全部应用接管

常说的 V2Ray 全局代理，需要说明是哪一层的“全局”。客户端中的全局路由通常让已经进入内核的请求优先走代理出站，但未进入客户端的应用仍不会因此改变路径。系统代理解决入口，路由预设解决出站，两者应分别设置。全局路由适合短时判断是否被分流规则影响；长期使用时，还要评估本地服务、局域网设备与日常直连业务的访问需求。

分开验证浏览器与其他应用

浏览器访问失败，先暂时停用会接管代理的扩展，再确认没有为当前浏览器单独指定另一套入口。客户端日志完全没有新连接时，应优先检查入口；日志已经记录请求并报远端错误时，再检查活动服务器和握手参数。测试前关闭旧页面或新建会话，避免复用旧连接。普通隐私窗口也不保证绕过所有网络设置，不能把它视为独立的代理环境。

命令行终端与部分开发工具不一定跟随系统代理。遇到浏览器正常、终端失败时，不要立刻更改可用的服务器。先查看该工具自身支持的代理设置，并使用实际监听地址和端口。HTTP 代理入口不能在所有场景中直接当成 SOCKS 入口填写，认证方式也需匹配。具体分支可查阅浏览器与终端分开排查，本阶段先保持单一入口便于定位。

最后做一次退出恢复测试：清除系统代理，确认普通直连访问恢复；重新启动客户端，再开启系统代理，确认目标访问恢复。这样能发现系统设置残留和自动启动顺序问题。只有当“开启后有效、关闭后可恢复”都成立，才算完成代理入口配置。若应用确实不能使用普通入口，再进入 TUN 章节，而不是为了一个应用先修改整机路由。

阶段六 · 调整出站

路由分流与 DNS 配合

从预设建立行为基线

先使用客户端提供的路由预设，不要一开始就导入来历不明的大型规则。“绕过大陆”通常用于让匹配到相应地域规则的请求直连，其他请求按预设走代理；“全局”用于让进入客户端的请求按全局策略处理。预设的具体规则内容可能调整，应打开路由设置检查实际条目。名称只是摘要，不代表每个局域网目标、特殊域名或应用都已经得到合适处理。

内核按规则配置与匹配逻辑选择出站，规则顺序会影响结果。宽泛规则放得过早，可能让后面的精确规则失去作用；没有命中任何规则时，还会落到默认出站。排查时同时检查命中规则和兜底行为，不要只看列表里有没有某个域名。新增规则前先写清目标：哪个域名或网段、希望直连还是代理、为什么需要例外，以及用什么请求验证。

把域名与 IP 规则分开理解

域名规则依赖客户端拿到相应域名信息，IP 规则则根据目的地址或相关解析结果判断。应用直接连接 IP 时，只有域名规则可能无法覆盖；一个域名背后使用多个地址时，只记住其中一个地址也不可靠。DNS 的职责首先是解析，并不会自动决定所有连接出站。路由策略、解析策略与连接时实际使用的地址需要配合，不能简单认为“换 DNS 就等于换出口”。

下面是内核级规则片段，用于说明字段关系，不是可独立启动的完整配置，也不应填入订阅 URL。它把示例域名及其子域名交给名为 direct 的出站，使用时该出站必须已经定义。图形客户端可能会重新生成配置，日常设置应优先通过路由界面完成，而不是反复编辑运行时文件。示例域名仅用于讲解，不代表应长期加入实际业务规则。

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

按单个目标定位分流异常

某个网站打不开时，先临时切到全局路由测试同一目标。若全局可用而原预设失败，重点检查规则命中、直连路径和 DNS；若两者都失败，则回到服务器或目标服务本身。每次切换后建立新连接，避免旧连接保留原来的出站。测试期间不要同时更换 DNS、节点和路由，否则即使恢复，也无法判断到底是哪一项生效。

访问路由器管理页、打印机或本地开发服务时，先确认私有地址与本地域名是否被正确直连。若代理出站尝试连接仅在本地网络存在的地址，远端通常无法到达。反过来，也不要为解决一个局域网目标而把过大的公网地址范围全部直连。嗅探可帮助部分连接恢复域名信息，但不能保证识别所有加密流量，还应考虑应用兼容性，按实际需要启用并验证。

规则维护应少而明确。为自定义条目写清用途，定期检查失效域名与过宽的匹配条件，更新规则资源后重新测试关键目标。切换网络时，先比较解析和局域网环境，再判断是否要改长期策略。完成本章的标准是能解释一个请求为什么走某个出站，并且知道未命中时去哪里；不是拥有更多条规则。下一步启用 TUN 时，应保留这套已验证的分流基线。

阶段七 · 扩大接管范围

TUN 模式与网络恢复

确认确实需要虚拟网卡

应用不读取系统代理，或需要让更多类型的连接进入客户端时，再考虑 v2rayN TUN 模式。TUN 通过虚拟网卡与系统路由接入流量，不是更快的节点，也不能修复无效的远端配置。先确保同一活动服务器在普通代理下可用，再打开 TUN。若普通代理尚未成功，新增虚拟网卡只会引入权限、路由、DNS 等变量，让原本明确的错误变得难以定位。

启用前保存当前可用配置，记录原有系统代理状态，并暂停其他会修改系统路由的工具。办公网络、远程接入工具和其他虚拟网卡可能与 TUN 竞争默认路由或 DNS。不要在依赖远程桌面的唯一连接上贸然测试整机接管；先准备本地操作或备用连接。受管理设备还可能禁止虚拟网卡驱动或提升权限，应先确认组织策略允许，而不是反复绕过权限提示。

按权限、路由、解析顺序检查

在 v2rayN 主界面找到“启用 TUN”，按系统提示完成必要授权。若启动失败，先查看日志中的权限不足、设备创建失败或地址冲突，再处理对应问题。没有成功创建虚拟网卡时，更换服务器通常没有帮助。能够创建网卡但所有访问失败时，再检查系统路由是否生效、默认出口是否正确，以及 DNS 请求是否有可用路径。设置名称因平台可能不同，以实际界面为准。

首次测试不要同时依赖系统代理和 TUN 来证明结果。按当前客户端的工作方式，暂时清除不必要的系统代理入口，再选择一个原本不读取系统代理的应用测试。若只有浏览器成功，仍可能只是浏览器沿用了普通代理。观察连接日志、目标访问和退出恢复三方面，确认接管链路真实成立。测试 UDP 应使用明确依赖该能力的应用，不能仅靠网页打开就推断支持情况。

保留局域网与特殊网络的边界

打印机发现、局域网共享、虚拟机和容器网络都可能受到路由变化影响。某个本地服务失联时，先确认目标地址与网段，再检查排除规则，不要直接把全部流量改为直连。DNS 接管也可能改变内部域名的解析结果，企业网络中的专用解析器尤其需要保留正确路径。登录公共网络认证页面时，可先关闭接管完成网络登录，再恢复并重新验证。

不要把 MTU 当作默认加速旋钮。只有在基础连接成立、部分连接出现稳定的大包传输异常，并且有明确测试依据时才考虑调整。随机更改数值可能掩盖真正的线路或协议问题。休眠、切换无线网络、连接热点之后若出现异常，先重建连接或重启 TUN，再比较路由变化。不同网络之间的故障不一定来自同一项配置，应分别记录环境。

需要恢复时先关闭 TUN，退出客户端，再确认系统代理没有残留；如果仍异常，检查其他网络工具与系统 DNS 设置，必要时重新连接当前网络。不要未经判断就删除所有系统网卡或重置整套网络。稳定使用的标准是常用应用、局域网访问、休眠唤醒和关闭恢复都通过测试。若普通代理已满足需求，也可以保持普通模式，把 TUN 留作有明确用途的选项。

阶段八 · 保持可维护

更新、备份与日常排错

分开安排三类更新

把客户端更新、内核更新和订阅更新分开看。客户端更新影响界面与配置管理，内核更新影响协议处理与运行行为，订阅更新则同步远端条目。三者不是同一件事，也不需要在出现故障时一起执行。先记录当前可用状态，再按需要更新一类，完成访问验证后再进行下一类。这样即使出现兼容问题，也能判断变化发生在哪个环节。

在“检查更新”相关入口操作前，阅读提示并保留配置备份；需要更换安装包时回到下载页按平台选择。不要为了追求新特性直接覆盖唯一的工作副本，尤其是已有自定义路由或复杂 DNS 设置时。备份应包含订阅来源、独立服务器资料、路由规则和必要的参数说明，但具体数据目录随系统与安装方式不同，应从实际客户端的数据管理入口确认。

备份需要能恢复，而不只是能复制

配置文件可能包含用户标识、订阅凭据和连接密码，应放在访问受限的位置。跨设备同步前先考虑同步服务的权限，不要把整份配置上传到公开分享目录。备份完成后记录所用客户端类型与主要设置，恢复时先在独立目录或受控环境验证。只复制运行程序通常不能保留用户配置，只保存截图又无法准确还原隐藏字段，两者都不能替代完整备份。

日常保留一份最近确认可用的配置，以及一份更新前的备份即可，不必无限积累带凭据的历史文件。迁移到另一台电脑时，先恢复基本订阅与活动服务器，再补充路由和 TUN。系统代理、驱动授权与本机端口属于设备环境，不应假定随配置文件一起迁移成功。确认新设备可用后，再按需要撤销旧设备的授权或清理旧资料。

用日志缩小问题，而不是反复重装

遇到 V2Ray 无法连接，先记录发生时间、目标应用、活动服务器、代理入口与最近一次改动，再看同一时段日志。解析失败优先检查 DNS 与域名；拒绝连接可能涉及端口或服务状态；安全握手错误应核对时间、服务器名称和安全参数；认证失败则回到身份资料。日志中的单次失败不一定代表整个服务不可用，要与实际访问和重复测试对应。

网速慢应分层检查：先换同一分组中另一条可用线路，再比较不同时间与目标，最后检查本机资源、网络接管冲突和分流设置。不要用延迟最小直接推断吞吐最高，也不要把远端目标限速归咎于本机端口。可按网速慢的分层排查方法保存测试记录。每轮只改一个变量，失败后回退，通常比累积一串未经验证的优化更有效。

分享日志前先脱敏：隐藏订阅地址、身份标识、密码和完整访问记录，只保留必要的错误上下文。临时提高日志详细程度有助于定位，但长期记录过细会增加磁盘占用和隐私暴露面，完成排查后应恢复合适等级。定期检查服务期限、自动更新结果和备份可用性，不要等到主用条目失效后才寻找原始资料。

最后建立一个简短维护顺序：先检查来源是否有效，再检查活动服务器，然后确认入口与路由，最后检查系统环境。重装只适合程序或配置确实损坏且已有恢复资料的情况，不是所有网络故障的第一步。保持少量明确的自定义设置，知道每项为何存在，才能在更换设备或切换网络后迅速恢复。

阶段九 · 扩展配置能力

进阶路线与配置验收

先读配置结构，再接触复杂组合

完成前八个阶段后，再学习内核配置的入口、出站、路由、DNS 与日志结构。目标不是把图形界面全部替换成手写文件，而是能读懂生成结果，知道某项设置最终作用在哪里。图形客户端会管理并生成运行配置，直接修改临时生成文件可能在重启或切换服务器时被覆盖。先区分用户持久设置、自定义配置和运行时文件，再决定改动位置。

阅读配置时从一条请求开始：它进入哪个入站，携带什么目标信息，经过哪些规则，最终选择哪个出站。再观察名称之间的引用关系，尤其是路由规则所用的出站标签是否实际存在。字段语法正确不等于业务逻辑正确，JSON 能被解析也不代表远端接受该参数。把语法验证、内核启动和目标访问作为三个独立验收环节，能避免停留在“文件保存成功”的误判。

按需求学习协议与 DNS

协议学习从已有服务需要的能力开始。使用 VLESS 时，先弄清用户标识、传输类型与安全层各自作用；涉及 REALITY 等特性时，逐项核对服务方要求，不要从另一条配置拼接参数。不同内核支持范围和默认行为可能不同，迁移前应检查实际能力。遇到陌生选项，先查对应内核的概念说明，再在独立条目中测试，不要直接覆盖主用配置。

DNS 进阶则从解析路径入手：哪个组件发起查询，查询走直连还是代理，返回地址如何影响路由，应用是否绕过系统解析。加密 DNS 不是自动解决所有隐私与连通问题的开关，它仍需要可用的网络路径，也可能与企业内部域名发生冲突。不要同时改动解析器、域名策略和路由资源；先保留可用基线，再逐层验证预期变化。

用场景清单验收完整方案

验收不要只测一个网页。分别测试普通浏览器、需要独立代理设置的应用、局域网目标和实际需要的 UDP 场景；再测试退出客户端、系统休眠、网络切换与重新启动。每个场景都要明确预期：哪些流量走代理，哪些保持直连，断开后是否恢复。若某项需求暂时没有，应记录为未验证，而不是因为一次成功就推断所有场景都可靠。

需要多设备使用时，优先让每台设备独立导入合法来源，按各自平台验证；只有明确需要共享本机入口，才研究局域网监听。扩大监听意味着其他设备可能接触代理服务，必须同时考虑认证、防火墙、网络可信范围和服务条款。不要把“允许来自局域网的连接”当成日常提速选项，也不要把本机管理接口暴露给不受信任的网络。

继续查阅时按问题选文章：不了解界面入口，读主窗口说明；不理解导入资料，读订阅与分享格式；入口与分流混淆，返回本页代理模式和路由章节。本站没有单独的问答页，常见操作问题可在使用文档的验证步骤继续定位，避免寻找不存在的菜单或页面。

完整配置的终点是可解释、可复现、可恢复：知道来源与权限，知道应用如何进入客户端，知道规则为何选择某个出站，知道更新失败时如何回退。保留一套简洁的主用方案，把试验放在独立配置中。今后遇到新协议、新网络或新应用，仍沿着概念、入口、出站、验证这条路径逐层推进，不必从头猜测所有参数。