本文包含 AI 创作

背景：
原本只是想安安静静地写代码、连 NAS，结果陷入了 Windows 11 的两大经典泥潭：明明能上网却显示“无网络”（NCSI 误判），以及优化启动项后导致的“系统级失声”（音频服务崩溃）。

💡 收获一：网络判定的“单行道”逻辑

现象： 浏览器能打开网页，Ping 也能通，但右下角始终挂着“地球仪/禁止符号”，系统应用（商店、Spotify）罢工。
核心教训：

  1. 网关即出口： Windows 的网络探测机制（NCSI）非常“轴”。如果有线网卡（仅用于连 NAS）配置了默认网关，Windows 就会固执地认为这根网线应该能通向互联网。一旦探测失败，它就会无视旁边正常的 WiFi。
  • 解法： 内网网卡（NAS/开发板）严禁配置默认网关，留空即可。
  1. IPv6 的干扰： 在双栈网络环境下，Windows 倾向于优先用 IPv6 探测。如果 IPv6 本地有地址但出不去，会直接导致误判。
  • 解法： 环境不支持时，果断关掉 IPv6 协议，强制系统走 IPv4 大道。

💡 收获二：音频服务的“身份验证”红线

现象： 蓝牙、有线、显示器音响全灭。服务列表中 Windows Audio 无法启动。
核心教训：

  1. 优化需谨慎： 类似火绒等工具的“启动项优化”，可能会误伤核心服务依赖，导致服务“假死”。
  2. 服务身份不能混用： Windows 的音频系统架构极其严格，两个核心服务必须“门当户对”，不能乱点鸳鸯谱：
  • Windows Audio 必须用 Local Service 身份（且密码留空）。
  • Endpoint Builder 必须用 Local System 身份。
  • 大忌： 手动输入账户名容易格式错误（如 NT AUTHORITY\...），必须使用系统的“高级查找”功能来通过 UID 匹配。

📝 遗留战场：蓝牙的最后倔强

有线音频已复活，服务架构已修复，但蓝牙耳机（Sony XM3）依然在连接层存在“幽灵”问题。这通常涉及 Windows 蓝牙协议栈与老旧设备驱动（尤其是 Hands-Free 通道）的深层冲突，或者蓝牙射频本身的干扰。

总结：
这次排查本质上是在和 Windows 的“默认行为”做斗争。

Windows 喜欢帮用户做决定（自动选网关、自动配 IPv6、自动管理服务），而作为高级用户，我们需要做的是：告诉系统，听我的，别自作聪明。