你关心的，这里有答案。

客户端的导入、更新、测速等操作先看存储目录中的 guiLogs；核心连接问题先看主界面信息栏。开启“日志存到文件”后也可查核心日志文件。

记录系统、客户端版本、核心版本、错误发生时间与最少复现步骤。只截取相关时段，隐藏订阅令牌、UUID、密码和私人地址。重复操作前标记时间，便于从旧日志中区分本次结果。

可以复制多份便携目录，分别保存配置和运行。每个实例需要不同的混合监听端口，并避开 +1、+2、+3、+4、+5、+21 等关联端口冲突。

多个实例不宜同时接管系统代理或 TUN 默认路由。为需要的应用手动指定对应实例端口，确认哪个实例负责系统设置。

本网站收录的 7.25.6 提供 windows-86 ZIP，对应下载页中的 x86。旧 Wiki FAQ 曾描述需要自行编译，这是历史说明；不要因此改用 x64 包。

同时检查 Windows 版本与核心的 32 位支持。32 位系统无法运行 64 位可执行文件，单独替换 GUI 架构也不能解决核心架构不匹配。

Windows 下载

当前发布说明要求 Windows 10 及以上，本页不把 Win7 列为受支持系统。旧系统同时涉及 .NET、界面框架和 Go 核心的兼容性，不能仅通过安装一个运行库保证正常。

升级系统后使用匹配包是当前下载路径。需要保留旧环境时，应将旧版客户端与其对应核心一起评估，不能混用最新核心并期待旧行为。

先在系统“关于”中确认 ARM64，下载 ARM64 包并完整解压。GUI 能启动但核心失败时，检查核心二进制是否也是 ARM64，以及当前协议是否受其支持。

官方 FAQ 中的旧设备兼容讨论不能作为所有 ARM 设备都能运行的保证。记录 Windows 构建号、处理器和报错，区分系统仿真、核心架构与配置问题。

Windows 的系统代理界面主要为使用该设置的应用配置 HTTP 代理。客户端混合监听端口本身同时支持 HTTP 和 SOCKS5，不需要系统界面同时显示两套才表示有效。

需要 SOCKS5 的应用可以在自己的代理设置中填写 127.0.0.1 和实际混合端口；HTTPS 请求经 HTTP 代理通常使用 CONNECT 隧道，不表示 HTTPS 内容被降为明文。

先确认核心正在运行，再查看 guiLogs 中系统代理脚本的错误。macOS 代理按网络服务设置，Wi-Fi 与 Ethernet 可能是不同项；切换网络后应检查当前正在使用的服务。

可在“系统设置 → 网络 → 当前网络服务 → 详细信息 → 代理”中核对地址与端口。需要手动配置时，使用 127.0.0.1 和客户端实际混合端口，并在停止使用后关闭手工开启的代理项。自定义配置应使用文件中实际监听的端口。

仅开启系统热点不会自动让其他设备使用本机代理。需要在客户端允许局域网连接，确认实际 LAN 监听端口，并让系统防火墙允许可信局域网设备访问该端口。

其他设备的代理地址填写这台电脑的局域网 IP，而不是 127.0.0.1，端口填写 LAN 监听值。保持设备处在可互通的网络；访客 Wi-Fi 或 AP 隔离会阻止访问。只在受控网络开放，使用后关闭不需要的监听。

在当前规则集中新增 direct 域名规则，将 geosite:steam@cn 与 domain:steamserver.net 放在代理兜底规则之前；先确认 GEO 数据包含该分类。

这是项目社区提供的分流思路，不保证覆盖所有地区和 CDN。重启 Steam 下载后查看真实连接目标与出站；若仍走代理，应根据日志补充实际下载域名，并区分商店、社区与下载流量。不同核心和规则资源的结果可能不同。

先确认普通网络能用，再检查节点是否有效、核心是否启动、应用是否把请求送到本地端口，最后检查路由与 DNS。开启 Debug 只复现一次需要的问题，记录首个相关错误，避免被后续连锁错误干扰。

1. connect refused：确认目标或本地端口有服务监听。
2. timeout：比较直连、当前节点和其他已知可用节点，缩小问题范围。
3. certificate / TLS：核对时间、SNI、证书链与固定值。
4. unknown field / unsupported：核对客户端与核心版本、完整模板。
5. 核心无请求日志：先查应用代理设置或 TUN 入口，不要先修改出口规则。

PAC 先由应用运行脚本；DIRECT 的请求绕过核心，因此核心路由和日志都看不到它。自动代理通常先进入核心，再执行路由分流。

同一网站结果不同，应先确认应用支持并实际使用哪种入口、PAC 是否缓存、例外列表是否匹配，然后再检查核心路由。

系统代理模式

先分别检查节点域名、DNS 服务域名和目标域名。DNS 服务地址本身为域名时，需要可用的 IP 形式 Bootstrap，避免“先连接代理才能解析代理服务器”的循环。

浏览器自己的加密 DNS、系统缓存、Hosts 和 FakeIP 也会影响结果。用默认 DNS 配置建立基线，再逐项开启自定义选项；不要把 Xray 路由解析与实际出站解析混为一谈。

DNS 基础与进阶

先记录具体域名、浏览器错误与发生时间，比较直连和代理结果。检查该域名是否被直连 / 阻止规则或系统代理例外提前匹配，再看 DNS 返回结果。

网站也可能按出口 IP、地区或账号状态限制访问。用其他已知可用节点对比可以帮助定位，但没有一条固定规则能解决所有 Bing 问题；不要直接关闭全部证书验证或删除所有路由。

记录完整错误，确认客户端具备运行该工具所需权限，且目标 UWP 应用已安装。部分精简系统或 LTSC 环境的应用组件可能不同，应先确认工具能枚举目标应用。

不要通过关闭整个防火墙来替代回环授权。如果问题只发生在单个应用，用普通浏览器对照测试，确认核心与系统代理本身正常，再处理该应用的沙盒限制。

项目讨论中有 TCP 拥塞控制相关的个案，也有端口占用和系统时间问题，不能仅凭“24H2”认定原因。先更新系统补丁，检查时间、核心日志和端口，再比较系统代理与 TUN 两种模式。

可用下方只读命令查看当前 TCP 设置。只有已定位到特定网络栈问题时，才针对该项调整并记录原值；不应把网上整套重置命令作为默认步骤。

Windows · PowerShell · read-only复制

Get-NetTCPSetting | Select-Object SettingName,CongestionProvider

先关闭 TUN，确认同一节点用普通系统代理可以连接。若普通模式也失败，先修复节点或核心。只有 TUN 失败时，检查权限、虚拟接口创建、默认路由、DNS 与其他 VPN / 虚拟网卡冲突。

按顺序尝试客户端默认设置、合适协议栈和较小 MTU，每次只改一项。局域网资源不可达时核对排除 CIDR。ping 可能由本地 ICMP reply 回应，不能独自证明代理连接成功。

TUN 参数

这通常发生在测试配置启动阶段，不等同于所有节点不可用。查看 Debug 中第一条错误，检查核心文件架构和执行权限、配置字段是否受支持、本地与测试端口是否占用。

临时测试使用基准端口 +21，且批量测试会消耗更多资源。Windows 虚拟化环境还可能保留某些端口范围。尝试一个节点和较小批次、换一个不冲突的基准端口，再看错误是否变化；不要直接删除系统保留范围。

能够传输某种游戏流量取决于游戏入口、TCP / UDP、核心和节点支持。许多游戏不使用系统 HTTP 代理，可能需要应用自身代理设置或 TUN。

代理不保证降低延迟；距离、线路、丢包和链式节点都可能增加延迟。先确认游戏可连，再比较同场景的延迟与稳定性，不能用浏览器测速代替游戏测试。

Windows 可在存储目录使用 NotifyIcon1.ico 到 NotifyIcon4.ico 对应系统代理状态的托盘图标。先备份已有图标，再放置有效 ICO 文件并重启检查。

规则集配置了自定义 PNG 图标时，会优先显示规则图标，系统代理图标变化不再直接呈现；因此图标没有变化不一定意味着代理模式没有改变。

系统关机时的退出处理不保证有足够时间完成。若下次开机没有运行客户端，系统却仍指向本地代理端口，应用可能无法联网。

重新打开客户端并选择清除系统代理，或在系统网络设置中关闭遗留手动代理 / PAC。之后正常使用时，先清除再退出可以减少残留。

可以使用这类路径，但外部核心、脚本、权限或同步软件可能引入额外限制。启动失败时可把完整便携目录复制到一个短、可写的本地路径进行对照。

在命令行引用带空格路径时使用引号。不要只移动主程序而丢失 bin 或配置文件，也不要把权限问题误当成编码问题。

客户端先组合入站、日志、路由与出站，再应用默认或自定义 DNS，并处理 Hosts 和节点解析。启用完整模板时，会将生成的代理出站整合到模板，其余由模板定义的内容可能覆盖普通设置。

最后启动核心执行生成结果。因此某个 GUI 设置“看似没生效”时，应检查是否启用了完整模板、自定义配置或显式 Core 类型，而不是不断重复修改同一个开关。