局域网连接需要重启本地网络隐私允许

[dacj4n]

主机环境：macos26.5
引用#948
问题：每次开机后重新启动netcatty都会网络中断，需要重新开启网络隐私

是否可能是这个参数的原因--disable-features=LocalNetworkAccessChecks导致没有检测本地网络权限

[binaricat]

谢谢反馈。先说你截图里那个 `--disable-features=LocalNetworkAccessChecks` — 它其实是 Chromium 网页层 Private Network Access 的开关,跟 macOS 系统那个"本地网络"权限不是一回事,关掉它也不影响 mDNSResponder/tccd 那一层判断,而且 Netcatty 这边并没有主动加这个 flag,是 Electron 默认带的。

macOS 15/26 上这种权限被反复重置的情况,Apple 已知会发生在应用签名或路径不稳定的时候。麻烦帮我看两个东西:

1. 终端跑 `codesign -dv --verbose=4 /Applications/Netcatty.app`,把输出里的 `TeamIdentifier` 和 `Authority` 这几行贴出来;
2. 系统重启后等问题复现,打开 Console.app,左侧选你的机器,搜索框里输 `tccd`,在连接 VPS 那一刻附近看有没有跟 Netcatty / local network 相关的 deny 行。

另外问一下,Netcatty 是从 dmg 直接拖进 `/Applications` 安装的,还是放在其他目录(比如 `~/Applications`)?

[dacj4n]

1. 命令codesign -dv --verbose=4 /Applications/Netcatty.app结果如下
   Authority=Developer ID Application: Qi Chen (H7WS5L2ML4)
   Authority=Developer ID Certification Authority
   Authority=Apple Root CA
   Timestamp=May 12, 2026 at 21:39:02
   Notarization Ticket=stapled
   Info.plist entries=33
   TeamIdentifier=H7WS5L2ML4

2. 同时控制台中没有发现deny，应该是已经授权了

在发包阶段没有收到返回包

3、是直接拖进/Applications安装的

[binaricat]

抱歉前一条直接掀了重写,你给的 debug 信息(签名 / TCC / 抓包)其实很有用 — 我手头没机器能本地复现这个 bug,主要是靠你这份证据加社区资料拼出来判断的。

先说结论: 这不是 Netcatty 自身的问题,是 macOS 15+ 上 Apple 自己一直没修干净的一个权限同步 bug,你这个症状(TCC 显示"已允许"、抓包出包发了无回包、关一次开关再开就好)跟社区里这个 bug 的典型表现是一致的。

机制大致是这样: macOS 把"本地网络权限"分两层处理 —— 一层是 TCC 数据库(系统设置里那个开关),另一层是 kernel 里的 NECP(Network Extension Control Policy)filter,由 nehelper 守护进程加载进内核。重启后这两层会失同步: TCC 写着"允许",但 nehelper 没把对应的 policy 推到 kernel,所以你发出去的 TCP 包能出去(syscall 层放行了),回包却被内核 filter 默默丢弃。"关一次开关再打开"等价于让 nehelper 重新 reload 一次 policy,这就是为什么 toggle 立刻就通。

参考资料:Apple 开发者论坛上有 Apple 工程师参与的 thread Local network access disabled after macOS restart;第三方做过技术拆解的有 coofdy.com 的分析 和 Michael Tsai 的综述;企业 IT 视角的 Rogue Research 复盘 也写得比较清楚。这也不是 Electron 特异的,Firefox 也踩过同一个坑,见 Mozilla Bug 1919889。

社区里比 toggle 更稳的 workaround 主要有两个:

• 退出登录再登回来(不用完整重启)。重新登录会强制 nehelper 完整重载所有 policy,粘性比单纯开关切换好。
• 如果上面这条还不行,实在没招就 删 /Library/Preferences/com.apple.networkextension.uuidcache.plist 再重启,这会让 NECP 整个 UUID 缓存重建,部分用户反馈之后权限能"粘住"。但它也可能顺带把别的网络扩展配置一起重置,不到走投无路别上,具体步骤参考 Zach Brown 这篇。

另外也有用户反馈 macOS 升级小版本之后频率会明显下降,你现在是 26.5,可以留意一下后续 minor update。

应用这边能做的不多 —— Netcatty 走的是 Node ssh2 → libuv → BSD socket,没办法用 Apple Network framework 那条更"原生"的路径显式触发系统重新评估权限;com.apple.developer.networking.multicast 那个 entitlement 是给 Bonjour 多播用的,跟我们 TCP 单播场景对不上,而且还得 Apple 单独审批。我这边会去 Apple Feedback Assistant 提一份 dupe(虽然有人提过,但加 +1 总归不坏),顺手把这个场景写进 README FAQ,后续遇到的用户能少走点弯路。

如果你还愿意再帮一次,有件事会很有帮助: 下次重启后先别动开关、让问题处在复现状态的那一刻,跑这两条命令把日志收一下:

sudo log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m
sudo log show --predicate 'subsystem == "com.apple.necp"' --last 5m

如果能看到 nehelper 里出现类似 Draining local network replies 或带 allowed=0 / bundle_id=null 的行,基本就锤实是上面那个同步 bug。我拿这份 log 提 Apple Feedback 比单贴截图说服力强一档,也许能催他们排进优先级。

[dacj4n]

necp.log
networkextension.log
上述为两个日志，其次我通过构建源码npm run dev发现是正常的，而npm run pack:mac后的 app 是失败的

[binaricat]

原因可能是在你机器上装的 Proxifier。

证据是 `networkextension.log` 里反复出现:

```
NESMTransparentProxySession[Primary Tunnel:Proxifier Data:...]: Plugin is registered
Found 1 registrations for com.initex.proxifier.v3.macos.ProxifierExtension
(com.apple.networkextension.app-proxy)
```

`com.initex.proxifier.v3.macos.ProxifierExtension` 是 Proxifier 自家的 Network Extension(initex 是 Proxifier 母公司),类型 `app-proxy` 对应 Apple `NETransparentProxyProvider` API —— 作用就是接管所有应用的 TCP/UDP 出站流量,按 Proxifier 内部的规则路由。这跟系统设置里的"本地网络权限"开关不是一回事,所以你看到 TCC 那一层 granted 但流量出问题,日志里的 `necp.log` 又几乎空白,完全合得上。

为啥 `npm run dev` 正常、`pack:mac` 失败:

Proxifier 是按应用路径/bundle id 匹配规则的:

• dev 模式跑的二进制是 `node_modules/electron/dist/Electron.app/Contents/MacOS/Electron`,bundle id 是 Electron 默认的 `com.github.Electron` —— 不在你 Proxifier 规则里,流量直连,LAN OK
• packed app 在 `/Applications/Netcatty.app`,bundle id 是 `com.netcatty.app` —— 匹配上了你某条 Proxifier 规则,SSH 流量被路由到一个到不了 192.168.x.x 的代理服务器,然后超时

至于"关一次开关再开就好了"为什么也起作用,我看了下日志里 Proxifier session 的 reset 事件每隔几十秒就来一次、跟你 toggle 的动作没有清晰对应关系,所以这一段机制我不下结论,可能只是 Proxifier 内部状态被某种刷新冲掉了一下。

真正的解法:在 Proxifier 里加一条 Direct 规则

1. 打开 Proxifier → Profile → Proxification Rules
2. 加一条规则,优先级放在所有"走代理"规则的前面:
   • Applications: `Any`(或专门写 `Netcatty.app`)
   • Target hosts: `localhost; 127.0.0.1; 192.168.0.0/16; 10.0.0.0/8; 172.16.0.0/12; 169.254.0.0/16; *.local`
   • Action: `Direct`
3. 保存,重启 Netcatty 试一下

这条规则的意思是"凡是连本机或局域网,无视上面所有代理规则,直连"。配上之后 Netcatty 连 LAN 就跟任何其他应用一样了。

可以试一下确认是不是这个吗?

[dacj4n]

并不是这个，我已经添加了规则，而且我的proxifier不会开机自启

[binaricat]

并不是这个，我已经添加了规则，而且我的proxifier不会开机自启

那我再研究下，这个问题我自己的mac上没有，issue我先打开着，有进展我会及时同步。不过我看之前贴的那些社区的帖子里 应该有一些做法你可以试试看能不能缓解。
感谢你的支持。

[binaricat]

有进展同步一下。后来在另一个几乎一样的反馈（#1040）里把根因挖出来了，跟你这个"TCC 显示已允许、但重启后连不上、要关一次开关再开"，以及"npm run dev 正常 / pack:mac 后的 app 失败"都能对上：

macOS 把「本地网络」授权绑定在 app 主程序的 Mach-O LC_UUID 上，而 Electron 预编译二进制是按内容哈希生成 UUID 的——同一个 Electron 版本构建出来的所有 app 共享同一个 LC_UUID（改 bundleId 都不影响）。dev 跑的是 com.github.Electron、打包后是 com.netcatty.app，但底层 UUID 是同一个，会和系统里别的 Electron 应用串台，导致授权"显示已给、实际没生效"。同类反馈见 electron-builder：electron-userland/electron-builder#9158

修复已经合进主干（#1041）：在打包（签名之前）给 Netcatty 写入一个 netcatty 专属、跨版本稳定的 LC_UUID，把它的本地网络授权和别的 Electron 应用隔离开。

这条我先关掉了，等下个版本发布后麻烦你升级试一下：升级后会需要重新授权一次「本地网络」（旧授权挂在那个串台的旧 UUID 上），之后看重启还会不会断。如果还是老样子，直接在这里回复，我会重新打开继续查。

非常感谢你前面贴的那些签名 / TCC / 抓包 / NECP 日志，帮了大忙。

[dacj4n]

已经成功修复，非常感谢☺️