必须正确配置接收方缩放（RSS）才能让Windows高吞吐Web业务充分发挥多核CPU能力，其核心是将不同客户端入站流量分散至多个CPU并行处理以避免单核瓶颈，需满足网卡硬件支持、兼容驱动安装、操作系统版本达标及逻辑处理器数≥2等前提，并通过PowerShell启用、合理设置间接表与CPU绑定、禁用已弃用卸载功能等步骤完成调优。
要让 windows 系统在高吞吐 web 业务中充分发挥多核 cpu 的处理能力，必须正确配置接收方缩放（rss）。它不是开个开关就能生效的自动功能，而是一套需软硬件协同、分阶段设置的机制。核心目标是：把不同客户端连接的入站流量分散到多个 cpu 上并行处理，避免单核瓶颈。
RSS 前提条件必须满足
启用 RSS 不是单纯改注册表或点一下 PowerShell 命令。以下三点缺一不可：
- 网卡硬件本身支持 RSS，并已安装对应版本的 Windows 兼容驱动（通常为 WDK 10 或更新驱动模型，如 NetAdapterCx）
- 操作系统为 Windows Server 2012 R2 及以上，或 Windows 10 版本 1607+；Web 服务器建议用 Windows Server 2019/2022
- 服务器逻辑处理器数 ≥ 2，且不依赖超线程核心做 RSS 分发（RSS 仅使用物理核心，超线程对 RSS 无增益）
确认并启用网卡 RSS 功能
先验证网卡是否已启用 RSS，再确保其处于活跃状态：
- 打开 PowerShell（管理员），运行：
Get-NetAdapterRss -Name "Ethernet"（将 Ethernet 替换为实际适配器名） - 若返回结果中 Enabled = False，执行：
Enable-NetAdapterRss -Name "Ethernet" - 若提示“此适配器不支持 RSS”，说明驱动未正确暴露 RSS 能力，需升级至厂商提供的最新 WHQL 认证驱动
合理设置 RSS 处理器数量与间接表
RSS 效果高度依赖间接表（Indirection Table）的大小和 CPU 映射策略。盲目设满所有核心反而可能因中断开销上升而降低性能：
Windows TTS (WSL2)
下载
在 Windows 11 上"直接发声"的 TTS（从 WSL2/TUI 调用 powershell.exe + System.Speech）。适用于用户说"说出来/读出来/语音播报/用TTS"，或反馈"没声音/tts 生成的 mp3 是空的/播不出来"，以及需要中文语音但 OpenClaw 内置 tts 不可用时。
- 默认间接表长度通常是 64 或 128，但实际有效条目应 ≤ 当前启用的物理核心数
- 推荐做法：将 RSS 绑定到非系统保留的核心（例如，若共 16 核，保留 CPU 0 和 1 给系统中断与调度，RSS 使用 CPU 2–15）
- 用命令限制 RSS 使用范围：
Set-NetAdapterRss -Name "Ethernet" -BaseProcessorNumber 2 -MaxProcessorNumber 15 -NumberOfReceiveQueues 14 - 避免跨 NUMA 节点分配——若服务器为双路 CPU，优先让 RSS 队列与本地内存节点绑定（可通过 numactl 工具辅助验证）
Web 场景下的关键注意事项
针对 IIS、Nginx（Windows 版）、或基于 .NET Core 的 Kestrel 服务，还需同步调整网络栈行为：
- 禁用 TCP Chimney Offload 和 IPsec Offload：这两项在 Windows Server 2016+ 中已弃用，开启反而引发连接重置或延迟抖动
- 确保 Web 应用监听在 0.0.0.0（而非 127.0.0.1），否则 RSS 对本地回环流量无效
- 若部署在 Hyper-V 虚拟机中，宿主机网卡需启用 RSS，且虚拟交换机应配置为“扩展模式”并启用 VMQ（虚拟机队列）；RSSv2 在 Windows 10 1803+/Server 2019+ 中可更好支持 VPort 级动态负载均衡
- 配合使用 netsh int tcp set global rss=enabled（该命令在较新系统中默认生效，仅作确认用）
配置完成后，可通过任务管理器 → 性能 → CPU → 查看各个逻辑处理器的网络中断（Interrupts/sec）分布是否趋于均衡，再结合 Web 压测工具（如 wrk 或 bombardier）观察吞吐与延迟变化。RSS 不是万能加速器，但对并发连接密集、请求轻量的 Web 服务，它是绕不开的基础优化环节。
