Steam Deck网络长期稳定：Wi-Fi省电、DNS、MTU与配置基线

很多人第一次在掌机上处理 Steam Deck 网络问题，走的是同一个路子：搜到一个叫 ToMoon 的插件，装上，重启，商店页面飞快，于是截图发群，说"永久解决了"。两周之后系统推了个更新，插件悄悄失效，Wi-Fi 又开始在合盖唤醒之后装死。我自己也这么干过一轮，后来把那台机器拆开看了才发现，真正让它长期稳定的从来不是某一个插件，而是把无线的省电策略、DNS 解析链路、MTU 和本地干扰这几件事按层摁死，然后用一套能回滚的配置基线锁住。这篇东西就是把这套流程完整摊开：先讲清楚 Steam Deck 的网络栈长什么样、故障怎么归类，再逐层给出可以直接抄的命令和配置文件，最后说怎么把"今天修好"变成"半年后还是好的"。适合手里有掌机、会一点命令行、但被"重启就好、过两天又坏"折磨过的人看。

1. 先把"网络问题"拆成四类故障，再谈工具

1.1 一台掌机的网络栈到底由哪几层组成

Steam Deck 跑的是 Arch 系的 SteamOS，网络这块从上到下其实是五层叠起来的，很多人排查时只盯着最上面一层，所以永远找不到根因。最上面是用户态的东西：桌面模式里 KDE 的网络面板、命令行里的nmcli、游戏模式里那个被大幅精简过的连接界面。往下是 NetworkManager 守护进程，它负责管理连接配置（profile）、下发 DNS、处理休眠唤醒事件。再往下是wpa_supplicant和iwd这类负责四步握手的认证组件，以及内核里的mac80211/cfg80211无线子系统。最底下贴着硬件的是无线网卡驱动和固件——Steam Deck 早期批次用的是 Realtek 的 Wi-Fi 5 方案，走rtw88驱动栈，后期和 OLED 批次换成了支持 6GHz 的 Wi-Fi 6E 方案，驱动栈也不一样。

这五层里任何一层出问题，你在屏幕上看到的现象几乎都是同一句话：网不好。但修法完全不同。认证层的问题表现为反复弹密码框、连上又断；驱动层的问题表现为休眠唤醒后设备直接消失，ip link里连wlan0都看不到；NetworkManager 层的问题最典型，配置文件被系统更新覆盖，看着一切正常但 DNS 永远是旧的；用户态的问题则经常是"游戏模式里显示连上了，桌面模式却打不开网页"这种诡异分叉。把层次分清楚，你才知道该敲哪条命令，而不是一上来就装插件。

1.2 四类故障的现象、归属层与验证手段

我把这两年遇到的案例归成四类，基本能覆盖九成以上的场景。这个表建议直接存下来，遇到问题先对号入座，比盲目搜索效率高得多。

断连型的排查入口在日志，不在设置界面。慢速型要先排除"是不是你选的下载区域本身就在远端"，再怀疑本地。首包慢型是四种里最容易被误判成"网络差"的，实际上很多时候只是 DNS 解析绕了远路，或者 MTU 没对齐导致大包被丢弃后反复重传。抖动型则几乎都跟物理环境有关，跟你装了什么插件关系不大。

1.3 为什么"一键插件"很难做到"永久"

这是我最想说清楚的一件事。这类插件的工作方式，通常是在系统里插入一层转发规则或者改写一批网络参数，让流量走一条它认为更优的路径。它在当天确实有效，但它的有效性建立在两个脆弱的前提上：一是系统里那些被它改写的文件不会被覆盖，二是插件自身跟得上系统更新。

问题就在这两个前提上。SteamOS 的更新机制会重置/etc下相当一部分配置，NetworkManager 的 profile 在一些大版本升级后会被重新生成；而插件依赖的运行环境本身也是要随系统演进的，宿主一变，插件就可能加载失败或者静默降级。你看到的"用了两周又不行了"，本质上是这两条依赖链中有一条断了。所以我的判断是：这类工具可以当临时手段用，但不要把它当成"永久方案"的载体。要做到"永久"，你需要的是不依赖任何单一第三方组件的配置基线，加上一套能让你随时退回上一个可用状态的机制。

2. Wi-Fi 省电策略：合盖唤醒后掉线的真正源头

2.1 现象复现与日志定位的完整链路

先把现象标准化，否则你没法验证修好没有。稳定的复现方法是：连上 Wi-Fi，进入游戏模式，按电源键休眠，等三分钟以上（短时间休眠不会触发深度省电），唤醒，立刻打开商店页面。如果页面加载超过十秒或者直接报错，而退出重连 Wi-Fi 之后又正常，那基本可以锁定是省电策略相关。

接下来去日志里找证据。切到桌面模式打开终端，跑这条：

journalctl -b -u NetworkManager --since "10 min ago" | grep -iE "sleep|resume|wlan|disconnect|reason"

重点看唤醒时刻附近有没有disconnect后面跟着一个 reason 码，以及wpa_supplicant有没有重新做一次完整的四步握手。如果每次唤醒都要重握手，说明链路在休眠期间被彻底拆掉了，而不是单纯休眠。再看驱动层：

dmesg | grep -iE "rtw88|rtw89|firmware|power"

如果出现enter deep power save之后没有对应的退出记录，或者有 firmware 重新加载的痕迹，那根因就在驱动的省电模式上。这一步很关键，因为很多人直接跳过去改 NetworkManager 的配置，改完发现没用——方向错了，问题在更下面一层。

2.2 两层省电设置的冲突：为什么你改了却没生效

Steam Deck 上的无线省电其实是两层同时生效的。上层是 NetworkManager，它有一个wifi.powersave的连接属性，取值 2 表示关闭省电、3 表示启用。下层是内核驱动模块自带的省电参数，Realtek 的rtw88栈里有跟深度睡眠相关的模块参数，名字随内核版本会有差异，先确认再改：

modinfo rtw88_core | grep -i parm

典型输出里会看到disable_lps_deep这样的参数，默认值往往是 0（即允许深度省电）。这两层的关系是：NetworkManager 关掉省电只影响它自己下发的那部分策略，驱动层的深度睡眠该进还是进。所以你会遇到那种"设置里明明关了省电，休眠回来照样断"的情况。正确的做法是两层一起摁住，而且还不能让设置在系统更新后被冲掉。

2.3 用 conf.d 和 modprobe.d 把配置钉死

不要用nmcli去改单个连接的属性，因为连接重建之后属性会丢。用一个独立的配置文件，让 NetworkManager 全局生效：

# /etc/NetworkManager/conf.d/99-wifi-powersave-off.conf [connection] wifi.powersave = 2

驱动层用 modprobe 配置：

# /etc/modprobe.d/99-rtw88-power.conf options rtw88_core disable_lps_deep=1

写完执行sudo systemctl restart NetworkManager，然后重新加载模块。注意重载无线模块会短暂断网，如果你正在用 SSH 连着机器，先确保有物理访问手段。验证方式：

iw dev wlan0 get power_save

输出Power save: off才算上层生效。驱动层则看dmesg里深度省电的日志是否消失。这两步做完之后再做一次休眠唤醒测试，如果还是断，那就不是省电的问题，回头去看 2.1 的日志里有没有认证层报错。

注意：/etc/modprobe.d下的配置对已经加载的模块不生效，必须重启或者卸载重载。滚动更新的系统里，配置文件有被包管理器覆盖的可能，改完记得把文件内容备份到你自己的目录里。

2.4 频段、信道宽度与掌机场景的匹配

省电搞定之后，下一个影响体验的是频段选择。掌机的使用场景很特殊：通常离路由器很近（同房间或者隔壁），但握持姿势会让手掌部分遮挡天线，而且机器经常在移动。这三个特点决定了频段选择的优先级跟台式机不一样。

5GHz 的优点是信道干净、干扰少、理论速率高，缺点是穿墙衰减快，遇到 DFS 雷达信道还可能被强制切走。2.4GHz 穿墙好但拥挤，尤其在家里有一堆智能设备的情况下，信道扫描出来经常是一片红。我在实际使用中的结论是：同房间用 5GHz，跨一堵墙以上手动切 2.4GHz，不要让系统自动在两者之间反复漫游——漫游过程本身就是掉线的高发时刻。

信道宽度也有讲究。80MHz 在干净环境下确实更快，但占用带宽大，遇到雷达信道时被动切信道的概率也更高；40MHz 是掌机场景下比较稳的折中。判断方法很简单，在桌面模式跑一次扫描：

nmcli -f SSID,CHAN,SIGNAL,SECURITY device wifi list

看你这台机器所在位置，5GHz 上如果附近 AP 数量少于三个，80MHz 可以用；超过五个，老老实实降到 40MHz，实测的体验反而更连贯。

3. DNS 与 MTU：加载卡顿和下载停滞的两个隐形推手

3.1 解析链路怎么测，别靠感觉

"页面加载慢"这件事，九成的人第一反应是带宽不够，但掌机上的带宽瓶颈其实很少见。更常见的是解析链路绕路：请求发出去，等了一百多毫秒才拿到 IP，然后才开始真正传输。这个延迟在单个页面上不明显，但商店页面一次要拉几十个资源，累加起来就是肉眼可见的白屏。

先测解析耗时，别猜：

resolvectl query steamcommunity.com systemd-resolve --statistics

第一条会给出解析结果和耗时，如果稳定在 100ms 以上，说明上游解析器离你太远或者有绕路。第二条看缓存命中率，如果 cache hit 很低而 transaction 很多，说明大量请求都在重新解析。我习惯用dig做对比测试，直接指定不同的解析服务器，看哪个快：

dig +stats @1.1.1.1 store.steampowered.com | grep "Query time" dig +stats @8.8.8.8 store.steampowered.com | grep "Query time"

同一条域名连测五次取中位数，比单次结果可靠得多。单次测量很容易被冷缓存误导。

3.2 把 DNS 写进 profile 而不是全局改 resolv.conf

很多人直接改/etc/resolv.conf，然后发现重启就没了——因为 SteamOS 上这个文件通常是指向systemd-resolved的符号链接，是动态生成的东西。正确做法是在 NetworkManager 的连接配置里指定，让它在每次连上时自动下发：

nmcli connection modify "你的SSID" \ ipv4.dns "1.1.1.1 8.8.8.8" \ ipv4.ignore-auto-dns yes nmcli connection up "你的SSID"

ignore-auto-dns yes这个参数是关键，不加上它，DHCP 下发的解析服务器会跟你的手动配置混在一起，实际走哪条取决于优先级，结果就是"有时候快有时候慢"这种玄学现象。改完之后用resolvectl status确认当前生效的服务器列表只有你配置的那两个。

提示：公共解析服务器在不同地区的实际表现差异很大，别人测出来最快的在你这里未必。建议自己列三到四个候选，用上面的dig方法各测一轮再定，别照抄别人的配置。

3.3 MTU 不对齐的症状与验证手法

MTU 这个问题隐蔽性更强。症状是：小请求（比如 DNS 查询、短文本接口）秒回，稍大一点的请求（图片、分段下载）就卡住或者超时重传，整体表现是"能连上但特别慢"。原因通常是链路上某一跳的 MTU 小于 1500，而你的设备还在按 1500 发包，大包被静默丢弃，靠 TCP 的重传机制慢慢探测，速度自然上不去。

验证方法是从 1500 开始往下试，看多大的包能带DF（不分片）标志通过：

ping -M do -s 1472 -c 3 1.1.1.1

1472是 1500 减去 IP 头 20 字节和 ICMP 头 8 字节的结果。如果这个不通但-s 1400通，说明链路的实际 MTU 在 1428 附近。逐步二分定位到具体值，然后把这个值写进连接配置：

nmcli connection modify "你的SSID" 802-11-wireless.mtu 1428

掌机接手机热点时这个问题出现频率特别高，因为移动网络的 MTU 经常不是 1500。如果你主要在用热点，建议单独建一个连接配置，专门针对热点场景设定较小的 MTU，别跟家里的 Wi-Fi 共用一个 profile。

3.4 Steam 下载区域、限速与缓存目录

下载速度上不去，除了链路问题，还有三个客户端侧的常见原因。

第一是下载区域。Steam 的下载区域是手动选的，选了一个远端节点，即使你本地带宽很大，实际吞吐也会被限制在节点到你这一段的能力上。在设置里换到离你物理位置近的两三个区域分别测一次，取最快的那个。这个操作的成本极低，但收益经常很可观。

第二是限速。客户端的下载限速设置在某些版本里会在更新后被重置为非零值，表现就是速度被稳稳地压在一个整数上（比如正好 10MB/s）。去下载设置里确认限速是关闭状态。

第三是缓存目录。中断的下载会在steamapps/downloading下留下不完整的碎片，有时候这些碎片会拖慢后续的校验和续传。空间紧张时更明显。清理方法是先完全退出客户端，再删除该目录下的残留内容，重启后重新排队。这一步不会丢存档，但会重新下载未完成的部分，心里要有个预期。

4. 局域网串流与蓝牙共存：被忽略的物理层干扰

4.1 串流的带宽估算，别凭感觉调码率

局域网串流卡顿，绝大多数人第一反应是调低码率，但调之前应该先算一下到底需要多少。以 1080p60 为例，H.264 编码在中等画质下的典型码率是 15 到 25 Mbps，HEVC 因为压缩效率更高，同等画质大约能省三成。再加上音频和协议开销，一条 1080p60 的串流实际占用在 20 到 30 Mbps 之间。

关键点在于留余量。无线链路的有效吞吐跟标称速率差得很远，2.4GHz 在理想条件下标称 300Mbps 的链路，实际稳定吞吐可能只有 40 到 60Mbps，而且波动很大。所以按经验，串流场景下无线链路的实测吞吐应该是目标码率的两倍以上，才谈得上"稳"。低于这个比例，你调什么编码器参数都是在赌运气。

测链路吞吐别用测速网站，那个测的是到公网的速度，跟局域网内两台设备之间的能力不是一回事。用iperf3在两台设备之间对测才准，掌机这边可以装一个客户端版本跑反向测试。

4.2 蓝牙手柄与 2.4GHz Wi-Fi 的互斥现象

这个坑我踩得挺深。有一阵子用蓝牙手柄配 2.4GHz Wi-Fi 做串流，表现是每隔十几秒卡一下，卡的时候手柄输入也会丢。一开始怀疑是编码器问题，换了几套参数都没用。后来把 Wi-Fi 切到 5GHz，卡顿直接消失——问题在物理层。

原因是蓝牙和 2.4GHz Wi-Fi 共用同一段频谱，蓝牙的跳频机制会和 Wi-Fi 的固定信道发生碰撞。掌机上天线和射频前端又是高度集成的小型化设计，隔离度有限，两者同时高负载工作时互相干扰几乎是必然的。表现就是周期性丢包，而不是持续低速。

排查方法很直接：用蓝牙手柄、Wi-Fi 走 2.4GHz，跑一次持续 ping，看丢包是否呈周期性；然后把 Wi-Fi 切到 5GHz，同样跑一次。两次结果对比，如果 5GHz 下丢包归零，那就实锤了。这个测试十分钟能做完，比反复调编码参数有用得多。

4.3 一组实测对比与最终取舍

我在同一位置做过一轮对比，条件固定：掌机距离路由器约 3 米无遮挡，蓝牙手柄连接中，串流 1080p60，每组测十分钟取平均。

结论很清楚：串流场景下 5GHz 是硬要求，蓝牙手柄能用但会引入轻微抖动，追求极致稳定就上有线。80MHz 那组虽然延迟数字最低，但丢包率反而比 40MHz 高，说明带宽开太宽之后对干扰更敏感。这也是我前面说掌机场景下 40MHz 更合适的实测依据。

5. 把"临时修好"变成"永久稳定"：基线与回滚

5.1 一份可版本化的配置基线清单

前面四章讲的都是单点修复。单点修复的问题是，系统更新一次、你手滑改错一次，前面所有工作就白做了。真正的"永久"靠的是把这些改动固化成一份可查、可比对、可回滚的清单。我给自己的机器建了这么一份表，每次动配置之前先对照，动完之后更新记录。

关键在最后一行。我习惯把/etc下自己改过的所有文件都复制一份到用户目录里，按日期命名，再写一个简单的脚本做定期比对。这样系统更新之后，跑一次diff就知道哪些配置被覆盖了，不用靠记忆去一条条排查。

# 简化的比对脚本 BASE_DIR="$HOME/net-baseline" mkdir -p "$BASE_DIR" for f in /etc/NetworkManager/conf.d /etc/modprobe.d; do diff -rq "$BASE_DIR/$(basename $f)" "$f" 2>/dev/null done

输出为空说明配置没被动过，有差异就说明需要重新应用。这套机制比任何插件都可靠，因为它不依赖第三方组件是否跟得上系统更新。

5.2 插件生态的风险边界与回滚路径

回到开头那个话题。第三方插件不是不能用，但用之前得清楚它的风险边界在哪里。这类工具通常需要系统级权限来修改网络配置，意味着它能做的事情远超它宣称的范围；它的更新节奏跟系统更新是两条独立的线，中间存在错配窗口；它的卸载过程未必干净，残留的规则有可能在你以为"已经删掉"之后继续影响连接行为。

我给自己定的规矩是三条。第一，装之前先做一次基线快照，把当前所有网络相关配置文件打包备份，这样出问题能整包退回。第二，只装在可以随时整体移除的运行环境里，并且确认过移除方法有效——很多运行环境的卸载入口藏得比较深，或者移除之后会留下残留目录。第三，只在明确知道要解决哪个具体问题时才装，不要"装一个看看效果"，那是给自己制造变量。

真出问题时的回滚顺序是：先卸插件、恢复基线快照、重启服务、验证三项核心指标（连得上、解析快、吞吐正常）。如果三步都做完还是不行，那就是更底层的问题，需要考虑恢复系统镜像。这条路径必须提前走通一次，别等到真出事才第一次尝试。

注意：任何需要系统级权限、又会改写网络配置的工具，都应该在你自己已经有一份干净基线的前提下使用。没有基线的机器上装这类东西，等于把唯一的退路也交出去了。

5.3 一套五分钟能跑完的自检脚本

修好之后的长期维护，其实不需要天天盯着。我写了一个自检脚本，每周跑一次，五分钟内出结果，任何一项不达标就去查对应的章节。

#!/usr/bin/env bash echo "=== 1. 无线省电状态 ===" iw dev wlan0 get power_save 2>/dev/null || echo "wlan0 不存在" echo "=== 2. 当前 DNS ===" resolvectl status | grep -E "Current DNS|DNS Servers" echo "=== 3. 解析耗时 ===" for i in 1 2 3; do dig +stats @$(resolvectl status | awk '/Current DNS/{print $3; exit}') \ store.steampowered.com 2>/dev/null | grep "Query time" done echo "=== 4. MTU 与连通性 ===" ping -M do -s 1472 -c 2 -W 2 1.1.1.1 >/dev/null 2>&1 \ && echo "1500 MTU 正常" || echo "MTU 可能偏小，需实测" echo "=== 5. 近期断连记录 ===" journalctl -b -u NetworkManager | grep -ci disconnect

这个脚本的价值不在于它多智能，而在于它把"感觉网不好"变成了五个具体的数字。省电状态是 on 还是 off、解析耗时是 20ms 还是 200ms、这周断连了几次——有对比才有判断。我在实际使用中发现，大多数所谓的"最近网变差了"，跑完这个脚本都能定位到具体是哪一项退化了，而不是玄学。

最后分享一个小技巧：每次系统大版本更新之后，别急着玩游戏，先跑一遍这个脚本，再跑一次休眠唤醒测试。更新会把/etc下的部分配置重置这件事，早点发现比晚点发现舒服得多。至于标题里那种"一键永久解决"的方案，我的态度一直是——临时救急可以用，但真正让一台掌机长期稳定的，永远是那几行你自己写下来、存好、能随时恢复的配置。