作者原文 · 预览@RPRX查看完整动态为了凑到第 2000 个 commit
以及给 Risaro 的生日补个礼物，我打算现在就分两步合并 XDRIVE 相关的 PR 进 main代码仍需完善，比如上面我提到的 XMUX，以及 config 的“Google Drive”改为“google-drive”，以及检测配置：需开启 mux.cool
可能还需要一些 deVibe，好在代码一旦进入 main 就会开始接受更广泛的 PR，会有很多人来完善，就像 XHTTP 那样还需配套的文档、Google Drive API 配置教程等，@Risaro 请发出你的 ETH 地址，我会给你转一个 Project X NFT 作为纪念
XDRIVE 将会是 Project X 2026 最具代表性的新协议，其次是 Finalmask、TUN，以及 FinalRules 等各种默认的安全改进
我很好奇，为什么你不推动 utls 本身的发展，反而要向一个只是使用其库的下游项目施压。显然，utls 是 Go 生态中非常实用的基础库，但目前没有得到足够的支持。既然你有这么多需求，为什么不直接为 utls 做贡献？ 这种情况与过去的 OpenSSL 十分相似：大量下游项目依赖这个库，却没有任何公司想到要资助它的开发。如果你认为 utls 的开发已经停滞，为什么不联系主要维护者，看看他们是否人手不足？ 我们也对 Xray 团队推出的任何新东西不感兴趣。鉴于他们对其他项目极其敌对的态度，我们不会再浪费时间迁就他们那些古怪的想法，包括但不限于他们打算使用 AI 拼凑出一个所谓的、完全没有经过安全审计的“指纹库”。 归根结底，如果你认为他们的想法和做法是正确的，我们建议你干脆只使用 Xray 作为唯一的软件解决方案。
作者原文 · 预览@wwqgtxx查看完整动态I am curious why you aren't pushing for the development of utls itself, rather than pressuring a downstream project that merely utilizes its library. Clearly, utls is a highly practical foundational library within the Go ecosystem, yet it lacks sufficient support. Given the volume of requests you have, why not directly contribute to utls?
This situation is strikingly similar to the state of OpenSSL in the past: a vast number of downstream projects relied on the library, yet no company thought to sponsor its development. If you feel that utls development has stalled, why not contact the primary maintainers to see if they are short-staffed?
We also have no interest in whatever new things the Xray team has come up with. Due to their extremely hostile attitude toward other projects, we will no longer waste time accommodating their eccentric ideas—including, but not limited to, their plan to use AI to cobble together a so-called "fingerprint library" that lacks any security auditing.
Ultimately, if you believe their ideas and methods are correct, we suggest you simply use Xray as your sole software solution.
频道原文 · 预览@clashbyhako查看完整动态全网首发：Clash 成为首个搭载 mihomo 1.19.31 内核的 Apple 客户端。
最新内核 + 全新 MIPS 网络栈，硬生生塞进了 Apple Network Extension 苛刻的内存墙。
iPhone / iPad / Mac / Apple TV，全平台同内核，同一天上架。别人还在等，我们已经在 App Store 了。
立即安装 → https://apps.apple.com/app/id6794257189
发行版本：iOS 1.0.9 / tvOS 1.0.12 / macOS 1.0.12本次重点：
- 四端同源：mihomo 1.19.31，上游发什么，你就用什么
- MIPS 栈首次登陆 Apple：iOS / tvOS 配置TUN.STACK改为MIPS 即可体验
- 体积砍半：iOS 173MB → 78MB (−55%)，macOS 298MB → 176MB (−41%)
- 切网无感：Wi‑Fi ↔️ 蜂窝、换网段，隧道不掉，网络保持畅通
- macOS：新增 EasyTier 出口节点，标签样式下可直接取消固定
- Apple TV：配置定时自动更新（到期打开即拉取）+ 每次更新自动运行脚本
💬 MIPS 栈和无感切网在你的主力机上表现如何？升级后欢迎在电报群里晒出内存占用与稳定性反馈，并说说你最想要的下一个功能。
电报交流 → https://t.me/+eCUP-ohH8xMwMzll
Leadaxe 在 LxBox 议题中说明，Happ 配置里的 VLESS + REALITY + Vision 节点本身不是内核限制，差异来自订阅面板按请求头返回不同节点；LxBox 可在订阅或全局设置中自定义 User-Agent 和 HWID，随后解析 Xray JSON 中的 proxy、member、balancer 与 burstObservatory，但不导入 Xray 路由规则和 DNS。
作者原文 · 预览@Leadaxe查看完整动态Hi! This is most likely not a core limitation. Both outbounds in the Happ config are plain vless + REALITY + vision, sing-box handles those fine. What differs is the servers themselves: note the different
shortIds (0c/1fvs26a8). Your provider simply hands out a different set of nodes depending on which client asks.The panel decides that by the request headers, and you can change both in LxBox:
- per subscription: open the subscription → settings → Fetch identity → enable Custom identity. There you get Custom User-Agent and Send HWID (
x-hwid, plusx-device-os,x-ver-os,x-device-model, all editable);- globally for all subscriptions: app Settings → Subscriptions, same fields.
So set the User-Agent to what Happ sends (and turn on Send HWID if the panel has device limits), update the subscription, and you get the Happ version of it, which LxBox can use as is. It parses Xray JSON configs:
proxyandmemberbecome nodes, and the balancer comes along too.routing.balancers+burstObservatoryturn into an auto-select node named afterremarks(yourroundRobinbecomes a round-robin pool over both servers, with the ping URL and interval taken frompingConfig). Only the Xray routing rules and DNS are not imported, LxBox has its own routing for that.Please tell me what you get after that: do the nodes appear, and do they pass the whitelist?
频道原文 · 预览@clashbyhako查看完整动态📢 【公告】TestFlight 申请通道已全面恢复
Clash 的 TestFlight 内测申请现已完全恢复正常，需要安装或更新的朋友可直接在群内唤起机器人申请！
🔗 电报交流群： https://t.me/+eCUP-ohH8xMwMzll
申请流程与常用指令：
- /start@clash_group_bot：发起内测申请（按提示输入并提交 Apple ID 邮箱）
- /status@clash_group_bot：查看当前申请进度与审核状态
- /cancel@clash_group_bot：提交前重填或修改邮箱
💡 温馨提示：
- 提交成功后请留意查收来自 Apple TestFlight 的邮件通知。
- 多端通用：iOS / tvOS / macOS 只要登录同一个 Apple ID 账户即可同步使用，无需重复申请。
频道原文 · 预览@OwnBoxs查看完整动态OwnBox v2.8.0 正式版
https://github.com/Own716/OwnBoxForAndroid/releases/tag/v2.8.0
增加新功能
• 全部分组聚合
• 节点列表延迟显示与即时排序
• 搜索多格式导出（剪贴板 / 配置文件）
• 搜索结果分享为二维码
• 免 Root 局域网共享独立面板
• 负载均衡前置代理与落地代理
• 负载均衡正则表达式规则过滤
• 物理触觉震动反馈
• 通知栏快捷重置连接修复和优化
• 性能优先模式与后台省电深度优化
• sing-box v1.15.0 内核与 Sing-Tun 原生网络栈
• Wi-Fi 与移动网络无缝平滑切换
• 搜索输入法候选词与键盘响应体验
• 落地 IP 探测与即时刷新
• 界面主题色彩与层级精简
yiguodev 在 Xray-core 的 Windows TUN 讨论中说，UWP 方案确实有效，已经应用到 OneXray 的 UWP 版本；但发布较费劲，需要自签名或上架 Windows Store。
作者原文 · 预览@yiguodev查看完整动态UWP 这个方案吧，确实有效，已经应用到 OneXray 的 UWP 版本里了。不过就是发布费劲，要么自签名，要么就得发布到 Windows Store 。
感觉 wintun 这个方案就是个绝路，给 DNS 打补丁也不一定有效。
在修复说明中表示，原因是创建 VLESS 时自动填充只生成 users[].uuid（与 Mihomo 官方一致），但校验强制要求 username，于是报 vless listener users[0] requires username。改动有三点：VLESS/VMess 的 uuid 模式校验只要求 uuid、username 改为可选；自动填充缺省时补 username: "user"；已有只填 uuid 的记录也会回填 username。更新到包含该提交的构建后即可正常新建 VLESS 节点。
作者原文 · 预览@kazeyukiro查看完整动态已修复（main）
原因： 创建 VLESS 时 autofill 只生成
users[].uuid（与 Mihomo 官方一致），但校验强制要求username，导致报错：
vless listener users[0] requires username改动：
- VLESS/VMess 的 uuid 模式校验：只要求
uuid，username可选- autofill：缺省时补
username: "user"- 已有仅 uuid 的行也会回填 username
更新到包含此提交的构建后即可正常新建 VLESS 节点。
liandu2024 在 Open-Box 议题中说明，v0.1.206 已加入「设置 → 后端设置 → 屏蔽 QUIC」且默认关闭；开启后代理线路的 UDP 443 会被拒绝，浏览器会回退到 TCP，直连站点和前置自定义端口分流不受影响，修改后需重启内核生效。
作者原文 · 预览@liandu2024查看完整动态v0.1.206 已加:「设置 → 后端设置 → 屏蔽 QUIC」,默认关。
打开后,走代理线路的 QUIC(UDP 443)会被直接拒绝,浏览器自动退回 TCP;直连的站点不受影响,你在前置自定义分流里按端口写的规则也不受影响。改完重启内核生效。
liandu2024 在 Open-Box #82 中说明，自定义安装目录暂不计划做，因为 /opt/open-box 写在 init 脚本、LuCI 页面、升级脚本和防火墙 include 等多处，改成可配置风险较大；N1 等 /opt 空间小的设备可把大分区 bind mount 到 /opt/open-box，并写入 /etc/rc.local 后再运行安装脚本。
作者原文 · 预览@liandu2024查看完整动态自定义安装目录暂不计划做:
/opt/open-box这个路径写在 init 脚本、LuCI 页面、升级脚本、防火墙 include 等很多地方,改成可配置风险比较大。N1 这类 /opt 空间小的设备,可以试试把大分区 bind mount 到
/opt/open-box(安装脚本检测空间时看的就是这个目录所在的文件系统):mkdir -p /mnt/mmcblk2p4/open-box /opt/open-box mount --bind /mnt/mmcblk2p4/open-box /opt/open-box再把这条 mount 写进
/etc/rc.local(放在exit 0之前)让它开机自动挂载,然后运行安装脚本。先关闭。
liandu2024 在 Open-Box 议题中说明，链式代理已在 v0.1.203 上线，可在「设置 → 链式代理」添加 socks5/http/https 出口并指定前置节点或节点组；生成配置会检查上游是否存在和是否成环，链式节点可进入手动节点组、站点集与终端分流。导入 Clash 订阅时，订阅里的 dialer-proxy 关系仍需手动建立。
作者原文 · 预览@liandu2024查看完整动态链式代理已在 v0.1.203 上线,对应你说的
detour方案:「设置 → 链式代理」里添加出口(socks5 / http / https,链接或分字段填写),指定前置的节点或节点组;生成配置时会核对上游是否存在、是否成环。建好后它作为一个节点出现,可以进手动节点组、站点集、终端分流,代理页和域名穿透里会分层显示「前置 → 链式节点」。目前还没做的一点:导入 Clash 订阅时,订阅里自带的
dialer-proxy关系不会自动带过来,需要在「链式代理」里手动建。请升级到最新版试用,有问题欢迎开新 issue。
近期 huarun.win 在中国大陆部分网络环境下出现无法直接访问（“被墙”）的情况，具体表现因地区及运营商而异。
本站目前运行正常，应用目录与历史资料仍在持续维护更新。
如遇无法访问，请尝试调整网络环境、DNS 或使用其他网络工具访问。
Leadaxe 说明 Xray 与 sing-box 在 gRPC serviceName 路径解析上的区别：Xray 允许斜杠前缀表示服务与流名，而 sing-box 始终在服务名后追加 /Tun 导致 404；singbox-launcher 在导入时已做转换，但多段斜杠仍受内核 URL 编码限制。
作者原文 · 预览@Leadaxe查看完整动态Thanks for the report — reproduced, and the cause is on our side.
In Xray, a
serviceNamethat starts with/is a different notation, not just a slash-prefixed name: the last segment is the gRPC stream name, so/xxxxx/something/Tunmeans servicexxxxx/something+ streamTun, and the request path on the wire is/xxxxx/something/Tun. sing-box takes the plain service name and always appends/Tun, so we were sending the whole string as the service name and the server saw a different path — hence the 404.The launcher (develop) now translates that form on import, so
/<service>/Tungives the same request path Xray would produce. One caveat: the core percent-encodes/insideservice_name, so a name with several segments (like yours) still cannot be expressed exactly — we have filed that with the sing-box-lx core. If you can, a single-segmentserviceName(/xxxxx/Tun) will work in the meantime. Leaving this open until the core side lands.
Leadaxe 介绍 singbox-launcher 在 Windows 下实现开机自启的设计：由于程序清单元数据需要管理员权限，放入常规启动文件夹会导致每次登录弹出 UAC 提示，因此改用计划任务脚本并支持静默启动与托盘运行。
作者原文 · 预览@Leadaxe查看完整动态Сделано: в Windows-архивы релиза (win64, win64-full, win7-32) кладутся два батника рядом с exe —
autostart_add.batиautostart_remove.bat.Add создаёт задание Планировщика
singbox-launcher: триггер «При входе в систему»,/RL HIGHEST, путь берётся из расположения самого батника, так что папку можно переносить. Remove удаляет задание. Оба требуют запуск от администратора и сами это проверяют.Именно через Планировщик, как вы и предлагали: ярлык в «Автозагрузке» не годится — манифест exe требует прав администратора, и UAC спрашивал бы при каждом входе. Описание — в
docs/BUILD_WINDOWS.ru.md, там же про флаги-start -tray(старт свёрнутым с поднятым VPN) и про задержку триггера. В develop, войдёт в ближайший релиз.
Leadaxe 说明 Linux 下通过 resolvectl 配置 DNS 时 CAP_NET_ADMIN 权限不足的根因在于 systemd-resolved 经由 D-Bus 且由 Polkit 独立鉴权；启动器不会静默安装系统规则，改由文档提供发行版通用的配置指引。
作者原文 · 预览@Leadaxe查看完整动态Thanks — this is a clean, well-scoped fix, and the diagnosis is right:
CAP_NET_ADMINcannot help becauseresolvectldoes the work throughsystemd-resolvedover D-Bus, and Polkit authorizes each of the four actions on its own.Your rule is now documented as-is in
docs/LINUX_DNS_POLKIT.md(and.ru.md): group setup, the rule,pkaction/idverification, the security reasoning and the uninstall steps; linked fromdocs/BUILD_LINUX.mdTroubleshooting and from the README (develop, ships with the next release).We deliberately do not install the rule from the launcher — it is a system-level change and stays an explicit administrator action; documenting it also keeps it distribution-agnostic.
Leadaxe 说明 singbox-launcher 将 Linux 默认 TUN 堆栈调整为 gvisor 的原因：原 system 堆栈在缺少 auto_redirect 时完全依赖 iproute2，容易被 firewalld 或 nftables 静默拦截；mixed 堆栈同样保留 TCP 上的 system 路径，因此直接默认采用 gvisor。
作者原文 · 预览@Leadaxe查看完整动态Thanks for the unusually thorough diagnostic — the SOCKS-inbound control test is what makes this conclusive.
Confirmed on our side: the launcher's own template hard-defaulted
tun_stacktosystemon Linux, while upstream sing-box builtwith_gvisordefaults tomixed. So this was the launcher's choice, not a core default. We also do not emitauto_redirectyet, which the sing-box docs recommend on Linux — without it thesystemstack relies entirely on iproute2 rules, and a firewalld/nftables policy can drop that path silently.mixedwould not help here either: it keeps the system stack for TCP, which is exactly what stalls in your report.What you can do right now: the selector already exists and persists — Wizard → Settings → "TUN stack" →
gvisor, then restart the VPN. Your"stack": "gvisor"output is exactly what it produces.Changed in develop: the Linux default is now
gvisor(template, with a note about firewalld/nftables in the setting's help text); it ships with the next release together with the template update. Exposingauto_redirectas a proper option is tracked separately, since that addresses the root cause of thesystemstack rather than working around it.
Leadaxe 确认 LxBox v2.24.0 中模板或预设 DNS 服务器的 JSON 标签页出现序列化回归，内联用户服务器不受影响；修复已进入 develop，后续将发布补丁版本。
作者原文 · 预览@Leadaxe查看完整动态Confirmed, thanks. It is a regression in v2.24.0: the JSON tab of a template/preset DNS server tried to serialize the model directly after the storage format change, so it failed on every such server. Inline (user) servers were not affected. Fixed in develop (03a77808), a patch release will follow.
Leadaxe 介绍 sing-box-lx v1.14.1-lx.4：REALITY 客户端开始应用 fragment 与 record_fragment，新增 tls.reality.key_share 的 classical 与 hybrid 选择，并说明旧版 Xray、新服务器和非 Chrome 指纹的兼容边界。
作者原文 · 预览@Leadaxe查看完整动态Ядро выпущено: sing-box-lx v1.14.1-lx.4 — обе части ядра из этого тикета в нём.
1.
fragment/record_fragmentтеперь действуют на REALITY (SPEC 088). Подтверждаю ваш разбор: REALITY-клиент строил uTLS-соединение на голом сокете, минуя обёртку фрагментации; опции принимались конфигом и молча не работали. Это поведение апстрима, не регресс форка. Теперь REALITY берёт ту же обёртку, что обычный uTLS-клиент; сrecord_fragmentClientHello уходит несколькими TLS-записями, сfragment— несколькими TCP-записями. Проверено на проводе тестами. Поможет ли это именно на вашей сети — не знаем: если middlebox не собирает сегменты и режет всё, чего не видит целиком, дробление сделает хуже; если он ищет группу или размер в первом сегменте — поможет.2.
tls.reality.key_share(SPEC 089, описание — lx-config §7):
""(не задано) — как несёт отпечаток, поведение без изменений;"classical"—X25519MLKEM768вырезан изkey_shareиsupported_groups, ClientHellochrome= 594 байта вместо 1720, один TCP-сегмент. По эффекту это то же, что вашfp=edge, но без подмены отпечатка. Только Xray < v26.9.8, новые серверы такой ClientHello отвергают молча (reality verification failed);"hybrid"— гибрид обязателен, на отпечатке без него (edge,ios, …) явная ошибка вместо тихого отказа сервера.Автофолбэк «гибрид → классика» не делали: по вашему же наблюдению сеть после первого гибридного пролёта около минуты не пропускает соединения к тому же серверу, повтор не помог бы.
Что осталось на стороне LxBox — по-узловая настройка
key_shareв UI (переживает обновление подписки, экспорт/импорт) с предупреждением про старые серверы. Тикет держу открытым до неё. Пока опцию можно проверить через Debug API, как вы делали сedge.Просьба к вам, раз сеть под рукой: на одном и том же узле сравнить три конфигурации —
key_share: "classical",record_fragment: trueс гибридом, иfragment: trueс гибридом. Это единственный способ узнать, срабатывает ли у оператора размер/сегментация или что-то ещё.По ветке «ТСПУ детектит X25519MLKEM768»: доказательств пока нет. Второй телефон того же оператора работает, провод работает, Chrome на вашем телефоне шлёт тот же гибрид на обычные сайты и не ломается; Xray-клиент (Happ) у вас тоже не проходит, значит дело не в форке. Xray-core #6256 описывает ровно этот симптом и закрыт как not planned. Различить «размер», «сегментация» и «группа» смогут только pcap с обоих телефонов.
RPRX 认为 XHTTP 不应依赖特定上层协议解决自身问题，并提出在 stream-down 中承载 packet-down 的设计方向，用于下行 keep-alive；他同时强调这不等于已经实现复杂的恢复连接或多路径策略。
作者原文 · 预览@RPRX查看完整动态
某位俄罗斯友人在私信中提到了该问题，我的看法是，目前来看“恢复连接”过于复杂且有局限性，比如需解决延迟、ACK 等问题、以及没有覆盖 https://github.com/XTLS/Xray-core/issues/4846 的需求，此外如果通过 mux 或 vision 的 padding 格式来发 keep-alive 包固然可以，但 XHTTP 作为一个独立的传输层，在设计哲学上不应过度依赖特定的上层协议来解决自身存在的问题，此外对 CDN 来说上行可以不活跃但下行得活跃，所以是时候开始设计 packet-down 的格式了，但不是 meek 那种，而是在 stream-down 中跑 packet-down，这也并不意味着直接实现了 https://github.com/XTLS/Xray-core/issues/4846 所需的复杂策略、multi-path-down 甚至多个相同包竞速，就像 packet-up 早有这些潜力但还没设计那样的配置，packet-down 的帧格式也需要保留这些潜力，大概五个要素：可省略的 session id 节选、可省略的包序号、不可省略的类型即 padding/data、不可省略的 length、实际数据，现在主要是利用该框架来发送下行的 keep-alive 包，obfs 是后话
但可以先开放周期、长度 range、padding 内容，至于服务端备份、客户端重排序、ACK 等，等拓展了“高级用法”再实现吧
Own716 在 OwnBox 议题中说明，OwnBox 使用 sing-box 核心，并未直接使用 Hev-socks5-tunnel；若追求类似的高性能、低延迟和全方位流量接管，建议选择 sing-box 自带的 Sing-TUN，并在设置中启用对应核心和入站选项。
作者原文 · 预览@Own716查看完整动态sing-box 核心，它并没有直接使用 Hev-socks5-tunnel，而是提供了现代代理软件中最主流的几种协议栈选项。
如果你追求类似 Hev-socks5-tunnel 那样的高性能、低延迟和全方位流量接管，建议你直接选择 Sing-TUN。
这四个选项的具体区别和适用场景如下：
Sing-TUN：这是 sing-box 核心自带的虚拟网卡引擎。它的定位和作用与 Hev-socks5-tunnel 完全一致，性能极高，对 TCP 和 UDP 的转发支持非常完美。它是目前大多数现代客户端中综合体验最好的引擎，非常适合打游戏和日常高强度使用。
（选择 Sing-Tun 之后，在设置里将禁用核和入站打开，就完美了。）
在 sing-box #4447 讨论中，xchacha20-poly1305 说明 Windows 服务进程不会读取交互用户的 HKEY_CURRENT_USER，因此 InternetSetOptionW 无法替当前登录用户设置系统代理；建议使用 tun.platform.http_proxy。
作者原文 · 预览@xchacha20-poly1305查看完整动态因为 WinINet 文档写了：服务进程不加载交互用户的 HKEY_CURRENT_USER，InternetSetOptionW 不能给当前登录用户设系统代理。所以是这是日常使用的用户和 Windows 图形客户端 daemon 不是同一个用户造成的问题。请改用
tun.platform.http_proxy。
madeye 说明 meow-android 的分支基于旧版 Compose 主分支，文件误放在多一个字母的包路径下会导致 Kotlin 重复声明；他在当前 main 上重建提交、保留原作者，并通过 Android lint 与单元测试。
作者原文 · 预览@madeye查看完整动态Maintainer edit: same issue as #71 — the branch was cut from a pre-Compose
mainand the file was added underio/github/madeeye/…(extrae) next to the existingio/github/madeye/…copy, which would fail with a Kotlin redeclaration error. Rebuilt the commit on currentmainat the correct path, authorship preserved; the effective diff is just the two@Volatilelines. Android lint and unit tests pass locally.
频道原文 · 预览@clashbyhako查看完整动态Clash for iOS 1.0.8 正式发布📱
已适配 iOS 27。
立即更新：https://apps.apple.com/app/id6794257189?platform=iphone
🧭 规则库
• 规则点开即可编辑，拖动即可排序。
• 出口可以直接选节点，包括订阅提供的节点；选出口时可以顺手新建策略组。
• 规则、策略组、规则集合都能点选创建，一步到位。
• 保存即生效，连接中改规则不用重连。
• 用了覆写脚本，也能再给配置加自定义规则。📜 覆写脚本
• 从链接导入的脚本可以一键更新，单条或全部；改动立即作用于当前配置。🔀 代理
• 分组行直接显示当前节点的延迟。
• 长按节点即可编辑。
• 展开过的分组会记住，下次打开还是那样。💾 存储空间
• 每一项可以单独清理；配置与 Geo 数据不再重复占用空间。建议所有用户及时更新至 iOS 1.0.8，也欢迎大家继续在社区反馈问题和建议： https://t.me/+eCUP-ohH8xMwMzll
频道原文 · 预览@clashbyhako查看完整动态Clash for macOS 1.0.11 正式发布💻
这一版主要是把规则和代理这两页做顺手：规则不用再进编辑器改文本，改完保存就生效；代理页一眼能看到每个分组当前走的节点有多快。macOS 27 发布后侧边栏和顶栏的显示问题，这一版也已经适配。谢谢频道里关于规则排序、存储占用的每一条反馈。
🖥 系统
• 适配 macOS 27。🔀 代理
• 分组行直接显示当前延迟，不用点进去看。
• 节点右键即可编辑。📋 规则库
• 规则可以直接编辑，拖动即可排序。
• 每条规则都能直接选择出口线路。
• 保存即生效，不用重新连接。📝 覆写脚本
• 一键更新，改动立即生效。💾 存储空间
• 每一项都能单独清理，相同内容不再重复占用。立即更新： https://apps.apple.com/app/id6794257189?platform=mac
建议所有用户及时更新至 macOS 1.0.11，也欢迎大家继续在社区反馈问题和建议： https://t.me/+eCUP-ohH8xMwMzll
Leadaxe 说明 LxBox v2.24.2 已加入简体中文界面，覆盖设置、节点向导、路由、DNS 及 Android 原生界面，并补充翻译字符串和全语言 CI 检查。
作者原文 · 预览@Leadaxe查看完整动态Done — Simplified Chinese ships in v2.24.2.
The whole interface is translated: settings, the node wizard, routing and DNS, plus the native Android surfaces (notification, Quick Settings tile, shortcuts). Pick it in Settings → General → Language → 中文（简体）, or leave the setting on System and it follows the device language.
The translation came from @wyphgsy in #137 — credit goes there. I brought it up to the current branch (58 strings had been added to the app since that PR was opened) and made the CI checks cover every language instead of Russian only, so Chinese cannot silently fall behind as new strings land.
Could you try it and tell me what reads wrong? I cannot judge the Chinese myself. The strings I added are the newest ones — Tailscale nodes and node sections — so those are the likeliest to sound off. Wording reports are welcome in this issue.
已完成 — 简体中文已在 v2.24.2 中发布。
整个界面均已翻译：设置、节点向导、路由与 DNS，以及 Android 原生部分（通知、快捷设置磁贴、快捷方式）。请在 设置 → 通用 → 语言 → 中文（简体） 中选择；若保持「跟随系统」，则会随设备语言自动切换。
翻译由 @wyphgsy 在 #137 中提供，功劳归于他。我将其更新到了当前分支（该 PR 提交后应用又新增了 58 条字符串），并让 CI 检查覆盖所有语言，而不再只检查俄语，这样中文就不会在新字符串加入时悄悄滞后。
能否请您试用并反馈哪些措辞不妥？ 我本人无法判断中文是否地道。由我补译的是最新的部分——Tailscale 节点与节点区块——这些最有可能读起来别扭。欢迎在本 issue 中反馈。
Leadaxe 深入解释 LxBox 的内存行为与底层设计决策：Go 运行时不会立即向操作系统归还堆内存，常驻内存体现的是会话峰值而非泄漏；过低的内存上限反而会导致 GC 占满 CPU；同时阐明基于自维护 sing-box 分支迭代的合理性，不采用 Rust 重写内核。
作者原文 · 预览@Leadaxe查看完整动态What you're describing is normal Go runtime behaviour, not a leak — and it's worth explaining because the number you're watching doesn't mean what it looks like.
Why RAM stays at ~400MB after you close the browser. Go does not return freed heap to the OS immediately. Memory that the collector has reclaimed stays mapped in the process and gets reused for the next allocations instead of being handed back and re-requested — that's cheaper than churning pages with the kernel. So RSS follows the high-water mark of your session, not the current number of connections. Going 340 → 430MB while a browser opens a few dozen connections, then settling near 400MB, is the runtime holding on to buffers it expects to need again. There is nothing to reclaim there; the memory is free from the program's point of view.
We did chase a real version of this, and it was the opposite problem. A hardcoded 200MB limit (v2.10.0) meant the collector ran continuously against a heap that couldn't fit — that was the "phone gets hot" reports, confirmed with a pprof CPU capture showing ~88% of CPU in GC. The fix was raising the ceiling, not lowering it.
So if you want to tune this: VPN Settings → System → Optimization → Memory limit. Default is
Auto, which picks by device RAM (200/384/512MB). Lowering it will not reduce steady-state usage in a useful way — it makes the collector work harder for the same job. There's also Suspend idle tunnels in the same section, which cuts heap substantially when the device is idle.On rewriting the kernel in Rust — no, and this isn't a performance judgement. LxBox runs on our own maintained fork of sing-box; that's what lets us debug all the way down and ship kernel fixes on our own schedule. Rewriting it would mean reimplementing every protocol, every transport and every routing behaviour from scratch, then re-verifying all of it on devices — years of work to arrive at the same feature set. The bottleneck in a proxy client is the network, not the language.
Elegying 在 SSRVPN #243 中说明，本次 AGP 9.4 工具链升级不完整：AGP 9.4 官方兼容表要求 Gradle >= 9.6，而该 PR 仍保留 9.1.0；项目的 built-in Kotlin 约定和依赖校验元数据也未配套迁移，后续应按完整工具链迁移单独实施。
作者原文 · 预览@Elegying查看完整动态关闭本次不完整的工具链升级。AGP 9.4 官方兼容表要求 Gradle >=9.6，本 PR 仍保留 9.1.0；项目的 built-in Kotlin 约定和依赖校验元数据也未配套迁移。旧 CI 红灯来自当时 Action 固定 SHA 的配置问题，不能算新工具链已验证。后续应按完整工具链迁移单独实施：https://developer.android.com/build/releases/agp-9-4-0-release-notes
liandu2024 在 Open-Box「节点切换不够丝滑」问题讨论中表示，从直连切换到代理会重启内核，反之也一样。
作者原文 · 预览@liandu2024查看完整动态你没理解sing-box的节点切换逻辑吧？从 直连 切到 代理，是会重启内核的，反之也一样
zn0wii 在 satelite-proxy「xray 内核版本过低」问题中表示，最新版内核与当前转换后的配置兼容性是个问题，试用最新内核后直接连不上，还需要研究研究。
作者原文 · 预览@zn0wii查看完整动态最新版内核跟当前转换后的配置 兼容性是个问题，试了最新内核，直接连不上了。还需要研究研究
liandu2024 在 Open-Box 功能建议讨论中答复：绕过大陆 IP 的一半已经在做，走直连的站点集里的 geoip 集合会编进内核的 route_exclude_address_set，开启 auto_redirect 时是一条 nft 集合规则，命中目标在系统入口直接放行、不进内核；若存在可能把同一 IP 送去别处的前置规则，旁路会自动关闭改走兼容路径。绕过大陆域名的一半任何工具都无法在防火墙层实现，因为入口只看得见 IP、域名需先解析。指定上游 DNS 方面，DNS 页的「兜底直连 DNS」给直连域名用，「代理 DNS 上游」给走代理的域名用；按单个域名指定其他上游目前不做。说明文档会随后补到 README。
作者原文 · 预览@liandu2024查看完整动态三个问题分别答一下:
- 绕过大陆域名 / IP 不进内核:IP 这一半已经在做了——此刻走直连的站点集里的 geoip 集合(默认「国内直连」里的 geoip-cn 等)会编进内核的 route_exclude_address_set,开着 auto_redirect 时就是一条 nft 集合规则,命中的目标在系统入口直接放行、不进内核;规则页「真实路由」测一个国内 IP 会显示「入口旁路,未进内核」。前面若有可能把同一 IP 送去别处的规则(前置自定义分流的域名行、走代理的终端分流、广告拦截),旁路会自动关掉改走兼容路径,原因写在部署结果里。域名这一半任何工具都做不到在防火墙层绕:入口只看得见 IP,域名得先解析;OpenClash 的「绕过中国大陆」实际也是按 IP 段做的,加上 FakeIP 过滤名单。
- 指定上游 DNS:DNS 页有两个上游可改地址和协议(UDP / TCP)——「兜底直连 DNS」给直连域名用,部署时优先用 WAN 下发的 DNS、读不到才用它填的地址,所以叫兜底;「代理 DNS 上游」给走代理的域名用,内核经站点集选中的节点向它查询。哪个域名用哪个上游由站点集此刻的出口决定,不用单独配;按单个域名指定别的上游(OpenClash 的 nameserver-policy)目前不做,把某个域名固定成某个 IP 或另一个域名可以用「DNS 重写」。
- 说明文档会随后补到 README。关闭。