LxBox / sing-box-lx 开发者
共 45 条动态，按原始发布时间排列。
查看人物介绍在 LxBox issue #165（请求为 Android 10+ 的 VPN 应用加入 http_proxy_support_in_vpn_apps）中，Leadaxe 表示该功能已在模拟器上实现并验证：开启「VPN 设置 → 隧道选项 → 系统 HTTP 代理」后，VPN 网络会通告 127.0.0.1:2081，Chrome 与 Play 通过 CONNECT 把 www.google.com:443 / play.google.com:443 转入内核的 syspr…（节选）
LxBox 作者在其仓库 issue #167（Проблема. В редакторе. Выделение）报告编辑器中的选区问题：无法拖拽选区边界，拖动时会连带拖动标签页与页面，并附界面截图。
在 shtorm-7/sing-box-extended issue #158（AmneziaWG 3.0 在 TUN 包且 ContentPaddingAddition > 16 时于 RoutineEncryption 触发 panic）中，Leadaxe 说明其自有 sing-box 下游（sing-box-lx）移植 AWG 3.x 的处理方式，与提案补丁略有不同：①注入元素按实际上界预留 tailroom，而非固定的 MaxMessageSize —— 设置 con…（节选）
在 LxBox issue #159（希望补充一个简单的 WARP detour 示例）中，Leadaxe 回复该配方已写入用户指南的「Double hop: the last server never sees your IP」一节，并指出「Chain or detour?」表格中与此相关的一行：chain 会把各跳保留为独立服务器，detour 则不会。随后关闭该 issue。
在 sing-box-lx issue #37（Hysteria2 经 MASQUE/IPv6 的 chain 代理不可用）中，Leadaxe 复现并定位为包尺寸问题、而非 dial 路径的 chain/detour bug：quic-go（hysteria2 使用）发送 1280 字节 UDP 载荷，IPv6 下整包为 1328 字节，超出 masque 隧道 1280 的 MTU，被用户态栈拆成 IPv6 分片后遭 WARP 丢弃；IPv4 分片可通过，故 IPv4 目标…（节选）
Leadaxe 在 sing-box-lx issue #36 说明根因与修复：XHTTP 客户端此前未把查询串从 transport.path 中拆出，整串经 path setter 上线，`/?proxyip=149.56.109.62` 被写成 `/%3Fproxyip=149.56.109.62/`（`?` 被百分号编码并带 stream-one 尾斜杠）。Xray 把 path 首个 `?` 之后当作请求 query（splithttp/config.go 的 Ge…（节选）
在 PR #35（为 sing-box-lx 增加更多 Linux 构建目标）的回复中，Leadaxe 表示暂不采用 UPX：不想在发布里放入重复的 Linux 归档（会多出 7 个产物），也不愿引入会重写已发布二进制的第三方工具，以及「在旧内核上无法启动」一类问题；路由器闪存不足可用外部介质（USB 优盘、extroot）并从其上运行内核解决。若继续更新该 PR，要求去掉 `upx` job、`release.needs` 中的 `upx` 以及 release notes…（节选）
针对「LxBox 无法建立 VLESS REALITY 会话而 NekoBox+ 同链接可用」，Leadaxe 说明 google_dot 横幅是节点探测未通过的连带结果。自 2.23.2 起内核不再从 chrome 指纹的 REALITY 问候中裁掉后量子密钥，ClientHello 变为约三倍大，在部分蜂窝网络下会丢失（见 #142）。建议在 2.25.10 上给链接加 `&key_share=classical` 或改用 `fp=edge`；若仍不行请另开 issue，…（节选）
在 sing-box-lx issue #34（TS_DEBUG_ALWAYS_USE_DERP + magicsock Rebind 泄漏 blockForeverConn，lxd Stop/Apply 永久挂起）的讨论中，Leadaxe 表示：根本原因与两种可能的修复已写入 SPEC 113（提交 d911831d2）。暂不修复——该开关是 tailscale 的调试开关、不属于任何 sing-box-lx 配置，修复需要 sagernet/tailscale 分支或新的…（节选）
在「如何实现 Proton/IVPN 之类的 VPN 经 WARP 出口」的提问下，Leadaxe 答复直接用 chain 即可，并附两张界面截图。他同时指出一个已知问题：创建时不会把标题纳入考虑，因此创建时要谨慎填写 tag。
回复「为 OpenWrt 提供压缩版」的请求：不计划官方提供 UPX 打包的二进制。原因：UPX 二进制每次启动会把整个二进制解压到匿名内存（当前 linux-arm64 约 75 MB），比普通二进制的按需分页占用更多内存，最需要小体积的 128 MB mipsle 路由器上反而可能导致 sing-box 或其他服务被 OOM 杀死；且 UPX 与静态 Go 二进制在部分架构（尤其 MIPS）有已知问题、弱 CPU 上启动更慢，每次 UPX 或 Go 新版本都需逐架构重测。…（节选）
修复已在 v2.3.4 发布：特权启动所用的 shell 现为 /bin/bash -p，处理日志之前会先检查是否以 root 运行，打开 classic.log 失败时会说明系统原因。若在 v2.3.4 上 classic TUN 仍无法启动，请提供错误文本以便重新开单排查。
在「macOS 27：TUN 自 v2.1.0 起不启动」问题（仍 open）中，Leadaxe 称原因已找到并在 macOS 26.7 上复现：与 macOS 27 无关，经典 TUN 不带服务时自 v2.1.0 起在任意 macOS 版本上都起不来。他确认了提问者的推断链 AuthorizationExecuteWithPrivileges → /usr/bin/env -i → /bin/sh -c：特权启动给工具 euid 0 而 real uid 仍是用户，并在环境…（节选）
在 singbox-launcher #138（anrock1985 于 2026-09-28 报告：macOS 27 上自 v2.1.0 起 TUN 无法启动，先报 classic.log 打不开、手动建文件后又报 Connect: operation not permitted，目前仍 open）中，Leadaxe 于 2026-09-29 09:47:47Z 说明两个现象出自同一条件：特权启动的 shell 以用户 uid 运行而非 root。目录 /Library/L…（节选）
Leadaxe 于 2026-09-29 08:06:22Z 在自己的仓库 singbox-launcher 提交 issue #139（目前仍 open）：远程机器（Linux，内核 1.14.2-lx.7）以 tailscale endpoint 且 advertise_exit_node: true 作为出口节点、手机（LxBox）以其为 exit_node 时，手机流量会绕过该机器上全部基于域名的路由规则——模板把 sniff 与 resolve 限定在启动器自身的入…（节选）
在 singbox-launcher #137（用户 deamon2k 报告以管理员启动后始终报 “core log C:\ProgramData\sing-box-lxd\logs\classic.log: C:\ProgramData: Все (S-1-1-0) is granted 0xd0040, must not be writable by a non-administrative account”，且在配置里把日志改到其他目录也无效）中，Leadaxe 说明：…（节选）
在 LxBox「开源版 Happ 替代品」议题中，面对「是否计划支持 Happ 的 Xray 配置、能否把 LxBox 当作 Happ 的开源替代、能不能提交只在 Happ 里能用的配置」的提问，Leadaxe 回复可以提交配置与服务器链接，并提出三点：一是链接里含隐私数据，建议通过 Telegram 提交而不是公开贴在议题里；二是他称 Happ 构建在 Xray 引擎之上，因此带有一些 LxBox 没有的、难以根治的问题，这里的配置来自 sing-box 而不是 Xray；…（节选）
Leadaxe 在 sing-box-lx #27（新增 DNS 策略的功能请求，已关闭）发布一份立场为「反对」的分析（原帖注明该分析由 AI agent Claude 代整理）：自动模式唯一的好处是不用手写域名列表，但代价更大——1）用 geosite 规则集挂 ipv6_only、其余走 prefer_ipv6，两条规则已能达到几乎相同的覆盖，验证码主要来自 Google 与 Cloudflare；2）若到达服务端的是域名而非 IP（sniff 的 override_de…（节选）
在 sing-box-lx #27（新增 DNS 策略的功能请求，仍 open）中，Leadaxe 说明为什么 prefer_ipv6 解决不了问题：它只在内核内部解析（Lookup）时生效，内核自己查 A/AAAA 并把 IPv6 地址排在最前；而 TUN 下的应用自己发查询，走的是 Exchange，A 与 AAAA 是两次独立请求，丢弃查询只发生在 ipv4_only / ipv6_only，prefer_ipv6 下 A 请求原样返回，应用拿到两个地址后自行选族（浏览…（节选）
在 sing-box-lx #28（fscarmen 提出、已关闭）中，Leadaxe 评估后决定暂不支持 Nowhere：Rust 实现 NodePassProject/Nowhere 创建于 2026-06-26，约 450 star、234 个提交里 233 个出自同一作者，线上格式仍在变（ALPN 已改为 nw2）；Go 版 nowhere-go 单人开发、1 star；Xray 与 sing-box 都没有服务端实现，订阅方不分发，用户得自己跑 nowhere po…（节选）
在 sing-box-lx 的 IPv6 问题（#26）中，Leadaxe 说他在真实 WARP 上验证过：IPv6 经 masque 在 vhttp: h2 与 h3 上都可用，curl 访问 https://[2606:4700:4700::1111]/cdn-cgi/trace 会返回 WARP 的 v6 地址且带 warp=on，ipv6.icanhazip.com 也能应答。他据此指出，多数「IPv6 不工作」不是出站问题，而是配置其余部分：一、tun 入站的 ad…（节选）
在「能否像安卓应用那样在订阅层面按协议过滤节点」的功能请求（#133）下，Leadaxe 答复「部分可以——引擎层面已有，界面还没有」。现有能力分两类：一是每个订阅/来源在启动器状态里都有 skip 列表，条目内的键全部匹配即丢弃该节点，支持的键为 scheme（协议：vless、vmess、trojan、ss、hy2 等）、tag、host、label、fragment、comment，写法支持 literal、!literal、/regex/i、!/regex/i，例如 …（节选）
在「XHTTP + H3 该怎么配置」的问题中，Leadaxe 回复称报告者的配置本身是正确的：此前 sing-box-lx 的 XHTTP 传输只在 TCP 上跑 HTTP/2，因此只开放 h3（QUIC、UDP）的 Xray 入站无法连通。他已在 v1.14.2-lx.2-rc.2 中改为按 Xray 的方式从 tls.alpn 选择 HTTP 版本（SPEC 104）：alpn 为 h3 时走 QUIC 上的 HTTP/3，为 http/1.1 时走 HTTP/1.1，…（节选）
在「服务器排成两列」的建议下，Leadaxe 答复该改动已列入计划：节点列表在宽度达到 600 dp 及以上时切换为两列布局，且只作用于节点页。该改动将在未来的版本落地，在此之前该问题保持 open。
在 Linux 打包测试的讨论中，作者答复 v2.1.0 已落地此前商定的目录布局：程序目录只读，数据放 $XDG_DATA_HOME/singbox-launcher，日志放 $XDG_STATE_HOME/singbox-launcher/logs；为打包与外壳脚本提供 SINGBOX_LAUNCHER_DATA_DIR、SINGBOX_LAUNCHER_LOG_DIR、SINGBOX_LAUNCHER_CORE 三个环境变量；二进制所在目录只读不再导致启动失败，他称这正…（节选）
在给应用选择器增加「一键选择俄罗斯应用」的提议下，作者回复合适的工具已经存在，并且不是应用选择器：俄罗斯应用已以 sing-box 规则集形式发布（legiz-ru/sb-rule-sets 的 ru-app-list.srs，规则项带 package_name），与提议里提到的来源相同。他说明理由：规则集在路由阶段按包名匹配应用流量，能覆盖域名列表绕不过去的 QUIC、ECH 与 CDN 域名，并且按内核的更新计划刷新，而不是随本项目的版本发布。用法是当前版本即可使用：路由…（节选）
对于「自动检测当前网络是否具备 IPv6 并切换」的提议，作者答复不予计划，并说明没有客户端这样做是有原因的：地址族策略是 sing-box 配置里的静态部分，改动它意味着重新生成配置并重启内核，因此「检测到 IPv6 就切换」会在每次 Wi-Fi 与蜂窝切换时断开全部连接，比它要解决的问题更糟。他也说明，若改为在内核内部每次拨号时检查默认接口是否具备全局 IPv6 地址，等于在 sing-box 之上自行定义一套语义，而这个问题在 DNS 设置里点两下即可处理。
在「仅代理模式下启动却要求关闭其他 VPN」的反馈中，作者确认这是缺陷：VPN 授权弹窗按模式做了区分，但启动时「另一个 VPN 正在运行」的检查没有做区分，因此在纯代理模式下也会触发，而该检查在代理模式下本不应生效。他表示修复正在进行中，待修复发布后关闭该议题。
在 AWG 连接失败的排查中，作者指出日志里的 disabled UDP GSO on 0.0.0.0:36771 不是发送失败：该套接字在第一个 GSO 批次上遇到 EIO，于是关闭 GSO 并在返回前把同一个包重发一次，这条信息每个套接字只输出一次；握手路径之所以把它记成 ERROR，只是因为它没有像数据路径那样解开重试标记，这一点之后会被调低日志级别，但它并不是连接不上该节点的原因。他判断真正的失败发生在这行日志之后，并请对方贴出后续日志：是否出现 Received h…（节选）
对于为 LxBox 增加 happ://crypt* 支持的请求，作者答复不会加入，并说明原因：该链接是对订阅地址做的一层 RSA 加密块，解密需要 Happ 应用内置的私钥，而这把私钥之所以出现在应用之外，是因为有人把它提取了出来；每出现一个新格式版本（crypt4、crypt5 等）就意味着要再追一把新密钥，而所附 HTML 在 crypt3 就已止步。他称这是闭源客户端与外界之间的追密钥游戏，LxBox 不参与，也不愿在 GPL 项目里分发他人提取的私钥；并指出即便解密…（节选）
