[hdward-dev]

问题

NixOS 上网络加速的 sing-box 放在应用数据目录 ~/.local/share/AsterDock/AppData/network-accelerator/core/，不走系统 PATH。这份核心常常是几十到几百字节的 #!/bin/sh 包装：它用 nix store 里的 ld-linux 去执行旁边的 sing-box.bin。

TUN 授权把 getcap 报出的 cap_net_admin 当成可用能力，于是把脚本复制到 bin/sing-box 并 setcap。内核不会把文件能力套到 shebang 脚本上，复制时又丢掉旁边的 sing-box.bin，启动以 127 退出，界面显示「加速核心已退出」。/dev/net/tun 和 setuid pkexec 本身是好的。

另外 SingBoxInstallerService 只接受 Windows / macOS，Linux 无法在应用内下载官方核心。

改动

• 包装核心不再走 setcap。 shebang 或非 ELF（包括 NixOS 的 ld-linux 包装）不会 UseCapableCopy / CopyAndSetcap。有 pkexec 时直接对原始脚本 LaunchWithPkexec，这样 $DIR/sing-box.bin 还在。已有的 bin/sing-box 和 .sha256 会被删掉，避免下次启动继续用坏副本。缺少 pkexec、用户取消、以及 NixOS 未启用 security.polkit.enablePkexecWrapper 的提示保持原样。
• pkexec 交接。 包装脚本 exec 之后 /proc/pid/comm 是 sh 或 ld-linux，不是 sing-box。只要进程已经不再是 pkexec，就视为授权完成，避免一直等到「等待授权超时」。
• 真实 ELF 仍可 setcap。 能持有文件能力、且 version 能跑起来的副本继续免密复用。副本 version 失败时改走 pkexec，并清掉这份副本。
• Linux 自动安装。 amd64 / arm64 下载 SagerNet 官方 sing-box-{version}-linux-{arch}.tar.gz，校验 Release 的 SHA-256，解出 sing-box 和随包的 libcronet.so，再跑 version。Windows / macOS 的包名不变。
• NixOS 没有动态链接器时。 官方 linux-amd64/arm64 包会请求 /lib64/ld-linux-x86-64.so.2（纯 Go 构建，但仍动态链接 glibc）。链接器不存在，或 version 报缺少共享库时，改下同版本官方 …-linux-{arch}-musl.tar.gz。该包是静态 ELF，不依赖系统 sing-box，也不依赖 nix-ld。两边都起不来时，提示设置 programs.nix-ld.enable = true;，或把已经能运行的核心放进应用数据目录的 core 文件夹。

验证

dotnet run --project tests/NetworkAccelerator.Checks --configuration Release（431 项通过）。另外用官方 1.13.12 的 linux-amd64 与 musl 包做了解包：动态包读出的解释器是 /lib64/ld-linux-x86-64.so.2，两个包的 sing-box version 都是 1.13.12。

在 NixOS 上

1. 删掉错误副本：rm -f ~/.local/share/AsterDock/AppData/network-accelerator/bin/sing-box ~/.local/share/AsterDock/AppData/network-accelerator/bin/sing-box.sha256
2. 若继续用现有的 Nix 包装脚本：打开 TUN。应出现一次 pkexec，然后 apphub-tun 起来。不要再复制脚本去做 setcap。
3. 若点「安装核心」：本机没有 /lib64/ld-linux-x86-64.so.2 时会自动改用官方 musl 静态包。第一次开 TUN 会为 setcap 再要一次 pkexec，之后复用带能力的副本，不再每次询问。启用了 nix-ld 时则安装官方动态包，行为与普通 Linux 相同。