最近手上这台 Jetson Orin NX 在往网盘传完一个大文件之后WiFi 直接掉线重连都连不上重启 NetworkManager 也没用。这个问题折腾了我一个周末翻日志、查电源、改配置总算把根因和可行的处理办法都摸了一遍。如果你也遇到“用网盘传大文件后 WiFi 消失”的情况尤其是在 Orin NX 这类嵌入式板子上这篇文章应该能帮你少走不少弯路。先说明一下这篇文章不是讲怎么修网盘客户端而是讲为什么一个纯应用层操作会把系统 WiFi 搞到“失联”以及从系统层面怎么排查、恢复和加固。内容基于 Jetson Orin NX 官方 Ubuntu 系统也就是 JetPack 环境不过大部分思路和命令在其他 Linux 板卡上也通用。1. 先搞明白传文件怎么把 WiFi “传没了”1.1 问题特征与常见误区我遇到的故障现象很典型用某网盘桌面客户端向云端上传一个约 20GB 的模型训练数据集上传进度接近 100% 时SSH 会话先卡住随后板卡 WiFi 断连。重新用有线连接查看执行nmcli发现 WiFi 被标记为“不可用”ip link里无线网卡的 STATE 是 DOWN/UNKNOWN而且扫描不到任何 SSID。很多人第一反应是“网盘服务把设备封了”或“路由器限制连接数”但大多数情况并不是。更常见的真相是长时间、高吞吐的上传任务把板卡自身的网络栈、内存、电源或散热拖垮最终导致 WiFi 模块假死或者驱动异常。可以把它理解为“把一辆小货车当重卡用”超载之后发动机先熄火而不是收费站不让过。1.2 为什么 Jetson Orin NX 更容易出现这种问题Jetson Orin NX 虽然算力很强但它的 WiFi 大多是 M.2 Key E 接口的模块比如 Intel AX2xx 系列或 Realtek 系列跟普通笔记本里的无线网卡不是一个体验。板卡通常只有 DC 供电散热方案也比较紧凑网卡模块紧挨着 CPU 和内存长时间满负荷上传时很容易出现模块温度过高、供电电压跌落、PCIe/USB 链路不稳定等情况。另一个关键因素是内存。Orin NX 在 JetPack 5.x/6.x 下默认会分一部分内存给 GPU系统可用内存本来就比标称值少。网盘桌面客户端上传大文件时通常会把文件切成块每个块都放进内存做校验和重传缓存再加上系统缓存页不断增长一旦内存压力过大内核的oom机制或网络协议栈异常就会让无线网卡变得极不稳定。简单说不是 WiFi “不想干活”是整机在极限状态下先崩了最弱的一环。2. 现场排查五分钟定位 WiFi 掉线根因2.1 先看网卡和系统状态出问题时不要马上重启先保留现场。通过有线网络或串口登录板卡依次执行这几条命令把状态记录下来nmcli radio nmcli dev status ip link iw dev rfkill list正常情况下nmcli dev status应该显示 wlan0 或 wlp 开头的设备状态为 connected/disconnected而不是 unavailable不可用。如果看到 unavailable通常不是连接配置问题而是射频被软件关闭或者驱动进入异常状态。这时再看一下rfkill list确认有没有“soft blocked / hard blocked”。再检查内存和负载free -h uptime sudo dmesg | tail -n 100dmesg是关键。WiFi 模块假死前通常会留下热警告、链路重启或者 PCIe 错误的记录。比如我这边看到的是ath10k_pci相关的 ce_report 错误如果模块是高通方案或者是iwlwifi报timeout。根据日志类型能快速判断到底是驱动层面、总线层面还是单纯电源/散热问题。2.2 用 dmesg 找内核日志里的线索如果日志里有这些关键词基本可以对号入座日志特征指向的问题thermal throttling/hot温度过高导致降频或模块关闭firmware error/timeout驱动与固件卡死需要复位PCIe link down/bus error无线网卡所在总线不稳定oom-killer内存不足系统开始杀进程wlan0: deauthenticated路由器主动断开或密钥协商超时这里有个容易忽略的点WiFi 掉线并不总是网卡本身的问题。如果上传期间dmesg里出现大量oom-killer或者kworker异常优先处理内存压力而不是回家把路由器换个遍。我见过不少人在这一步骤浪费时间最后发现是网盘客户端把 8GB 内存吃掉大半系统连基本网络服务都保不住。2.3 隔离测试是硬件还是系统为了区分“网卡彻底坏了”和“系统配置把网卡锁死”可以做两步隔离测试。第一步物理断开网盘上传任务等待 5 分钟然后执行sudo nmcli radio off sleep 3 sudo nmcli radio on sleep 5 nmcli dev wifi list如果 WiFi 能重新扫描到网络说明模块硬件没烧多半是系统层面的软锁或电源管理导致。第二步用有线网卡连接在完全不做任何上传的情况下长时间挂机看会不会再次掉线。如果不再掉线说明问题与高负载上传强相关接下来就可以针对电源、内存、网络管理三方面做处理。如果还是会掉线那就要查无线网卡本身的固件版本、天线接触和散热。3. 三大高频根因与对症解决方案3.1 电源/散热导致的 WiFi 模块假死Jetson Orin NX 的供电要求比较严格标称 7-20V DC 输入但很多第三方电源适配器在峰值负载时纹波很大或者电流余量不足。当网盘上传让 CPU、GPU、WiFi 模块同时高负载运行时瞬时电流可能突破适配器能力电压跌落直接让无线网卡复位。怎么判断用sudo jetson_clocks释放全部性能然后用tegrastats观察温度与功耗sudo tegrastats如果主芯片温度超过 85°CWiFi 模块又紧挨着主芯片基本可以认定是热环境问题。这种情况的解决方向有几种换成官方 19V 或符合功率要求的电源不要用手机充电头凑合。给机箱加一个主动散热风扇或者至少确保 WiFi 模块上方有气流。在/etc/rc.local或 systemd 服务里把 WiFi 模块的电源管理设置为关闭减少模块频繁降功耗带来的不稳定。补充一点很多 M.2 无线网卡默认开启了 IEEE 802.11 电源管理也就是所谓power save模式。嵌入式 Linux 下这种模式偶尔会让网卡在长时间高负载后进入低功耗状态而无法恢复。后面第 4 节我会给出关闭方法。3.2 内存耗尽与缓存堆积拖垮网络栈网盘客户端尤其是 Electron 套壳的桌面客户端在上传大文件时内存占用非常夸张。我在 Orin NX 8GB 版本上实测某网盘客户端上传 20GB 文件时RES常驻内存达到 4.2GB系统缓存还有 2GB 多剩下的可用内存不足 1GB。如果这时还在跑推理任务或训练脚本妥妥触发 OOM。在dmesg里看到类似Out of memory: Killed process 1234 (xxx)的记录说明系统已经动手杀进程了。网络管理器、DHCP 客户端、wpa_supplicant 这类服务优先级不高很可能被内核选中终止于是 WiFi 就“连接不上”了。解决思路很直接给网盘上传腾出内存空间或者限制客户端的缓存行为。上传前执行sync sudo sh -c echo 3 /proc/sys/vm/drop_caches清掉页缓存。给 Qt/Electron 客户端加--disable-dev-shm-usage或者设置环境变量限制内存但这类方法要看客户端支不支持。最稳妥的方案是改用命令行上传工具比如 rclone、aria2 配合网盘 WebDAV把并发数调低。也可以临时增加 swap 文件虽然不能根治但能避免 OOM 杀关键进程。增加 swap 的方法很简单sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile注意SD 卡或 eMMC 上开 swap 会影响寿命但如果用的是 NVMe SSD临时开 4GB swap 是很划算的保命手段。3.3 网盘客户端与网络管理服务互相打架第三种情况是软件层面的冲突。Jetson 官方系统默认用 NetworkManager 管理网络但网盘客户端有时会自己创建虚拟网卡、改路由表或者占用 DNS 端口。尤其是一些网盘客户端带有“加速上传”功能会在用户态做多线程并发甚至直接操作 socket 缓冲搞到一半把网络栈的 buffer 耗尽。看路由表和 socket 状态能发现端倪ip route ss -tunap | grep -i yourclientname如果路由表多了一条奇怪的0.0.0.0或192.168.x.x网关或者网盘客户端占用了大量 TIME_WAIT 连接基本就是它在搞事。这类问题的处理优先级是不要同时使用 NetworkManager 和 wicd/connman 等多个网络管理器容易出现配置互踩。网盘客户端里关闭“P2P 加速”或“多线程并发上传”选项。如果客户端不听话直接改用它支持的 WebDAV/FTP 接口绕开客户端。还有一种容易被忽略的情况网盘上传把路由器连接数打满导致 DHCP 续约失败。具体表现是 WiFi 关联正常但拿不到 IP或者获取到 IP 后上网几秒就断。这时需要看路由器的连接数限制通常把网盘客户端并发线程调低即可解决。4. 实战让 WiFi 在长时间上传下保持稳定4.1 紧急恢复连接的完整操作遇到 WiFi 断了连不上时按下面顺序操作能解决大部分软故障。先通过有线 SSH 登录依次执行sudo systemctl restart wpa_supplicant sudo nmcli radio off sleep 5 sudo nmcli radio on sleep 5 sudo nmcli dev wifi connect 你的SSID password 你的密码如果nmcli报错device not ready就强制重置网卡sudo ip link set wlan0 down sudo rmmod iwlwifi # 注意换成你的无线网卡驱动名 sudo modprobe iwlwifi sudo ip link set wlan0 up这里假设你的驱动是iwlwifi如果是 Realtek 或其他厂商先用lsmod | grep wifi或lsmod | grep 80211找到模块名。重置驱动后再执行一次nmcli dev wifi list能扫到网络基本就活了。最后一步是恢复 DHCP 状态sudo dhclient -r wlan0 sudo dhclient wlan0这几步做完90% 的连接不上问题都能恢复。如果还不活再考虑重启板卡。4.2 关闭 WiFi 省电减少掉线概率前面提到电源管理这里给出实际配置。NetworkManager 可以强制关闭 WiFi 省电模式sudo nmcli connection modify 你的SSID wifi.powersave 2也可以通过配置文件全局设置sudo nano /etc/NetworkManager/conf.d/wifi-powersave.conf写入[connection] wifi.powersave 2注意2是禁用省电3是启用省电。修改后重启 NetworkManagersudo systemctl restart NetworkManager很多 Intel WiFi 模块在省电开启时长时间挂机或高负载传文件后会出现延迟飙升、掉线无法重连。关闭省电虽然会增加一点点功耗但对嵌入式设备稳定性来说非常值得。另外可以通过iw直接查看当前电源管理状态iw dev wlan0 get power_save显示Power save: off就代表配置生效。4.3 用 rclone 替代桌面端网盘客户端我这里真心建议在 Jetson Orin NX 这种资源紧张的板卡上上传大文件不要用图形界面网盘客户端。无论哪个网盘桌面端都非常吃内存和 CPU。图形界面在远程无人值守的场景下也不好用SSH 断开就得靠 screen 或 tmux 续命本身也是坑。我现在的标准方案是 rclone tmux。先安装 rclone然后配置网盘的 WebDAV 或官方 APIsudo apt install rclone rclone config配置完成后用下面的命令上传限制并发数、限制带宽避免把板卡打满tmux new -s upload rclone copy /data/dataset remote:backup/dataset \ --transfers 2 \ --buffer-size 64M \ --drive-chunk-size 256M \ --progress--transfers 2的意思是同时只跑 2 个上传任务对 WiFi 和内存的压力都很小。--buffer-size 64M是每个任务的内存缓冲别设置太大。如果你的网盘是 WebDAV可以再加--low-level-retries 5和--retries 3断网后能自动重试不会一掉就崩。用 rclone 后系统内存占用从 4GB 降到了 200MB 以内WiFi 再没因为上传任务掉过线。这不是 rclone 本身多神奇而是它没有 Electron 那层壳也没有各种花哨的动画和自动更新模块资源占用完全透明可控。4.4 更新驱动与固件的正确姿势如果你的无线网卡在长时间高负载下频繁出问题可能是 JetPack 自带的内核驱动太老。Jetson 的 L4T 内核不是主线 Ubuntu 内核直接apt upgrade有时不会更新 WiFi 驱动。需要先确认无线网卡型号lspci | grep -i network lsusb | grep -i wireless确认型号后去网卡厂商或内核源码页面对应驱动版本。如果网卡是 Intel AX210/AX211可以先启用 Intel 官方的最新固件包把新固件放到/lib/firmware下。这个方法需要谨慎因为 Jetson 的驱动和固件必须与内核版本匹配乱放文件会导致网卡完全无法初始化。更安全的做法是通过 NVIDIA 的 SDK Manager 更新整个 JetPack 版本到最新发布版。最新版 L4T 往往包含对新一代 WiFi 模块的支持修复。但刷机有成本不是首选。我的建议是如果上面那些内存、电源、省电优化都做了WiFi 依然一传大文件就废再考虑刷机更新。不然的话稳定优先别折腾。更新固件后顺手检查无线网卡的天线有没有松。很多时候板卡在运输或长期使用后M.2 卡的两根天线接头会松动信号弱了之后长时间高负载传输就容易掉线跟驱动反而没关系。拧紧天线接头后同样的位置信号强度能从 -70dBm 回到 -50dBm整机稳定性会有明显改善。5. 常见问题速查与我的经验笔记5.1 问题排查速查表把这次排查过程整理成速查表下次再遇到可以少翻命令。现象优先检查快速处理WiFi 显示 unavailablerfkill list、nmcli radionmcli radio off on或重置驱动模块WiFi 能连上但无法上网路由表、DNS、DHCP 租约dhclient -r wlan0 dhclient wlan0传文件途中掉线且无法重连温度、电源、内存日志查看tegrastats清缓存检查供电掉线后几分钟自动恢复WiFi 省电模式设置wifi.powersave 2频繁 OOM 导致关键服务被杀内存占用、swap禁用页面缓存清理客户端添加 swap网盘客户端上传速度高时必掉线客户端并发设置换成 rclone限制--transfers这张表的内容是我实际踩坑后总结的不一定覆盖所有情况但至少能让你在 WiFi 断掉的时候不慌知道从哪里下手查。5.2 几个值得养成的习惯第一给 Jetson Orin NX 长期跑上传或下载任务时优先使用 USB 千兆有线网卡。这东西几十块钱比花几天排查 WiFi 不稳定划算太多。WiFi 适合做轻量连接和远程调试不适合长期高吞吐传输这跟板卡本身无关是 2.4G/5G 无线信道在嵌入式天线布局下的物理限制。第二定期清理网盘客户端的缓存目录。很多桌面客户端会把已上传的分块文件暂存在用户目录下上传完也不自动清掉日积月累会把 eMMC 或 SSD 空间占满。磁盘满了之后不仅 WiFi 连不上整机都会变得卡顿。第三上传大文件前先看一眼系统状态。养成一个习惯free -h df -h / uptime如果可用内存低于 1GB或者根分区满了先处理再传。我就吃过一次亏明明 WiFi 没问题因为磁盘满导致 wpa_supplicant 写不了日志间接让连接极不稳定查了半天才发现是日志把 100MB 的 /var 分区撑爆了。最后说一点个人体会。Jetson 平台是一个“麻雀虽小五脏俱全”的嵌入式电脑性能和功耗的平衡很微妙。很多 WiFi 问题看起来玄学归根结底是资源不够、电源不稳、配置不当这三件事。遇到问题不要先怀疑路由器先查日志再看硬件最后调配置。按这个顺序来你会发现绝大多数“连接不上 WiFi”的问题都能在十分钟内找到方向而不是盲目敲命令。 
长河君 · 2026/9/27 20:31:00 · 阅读 1.2k Jetson Orin NX传大文件WiFi掉线？根因排查与解决方案
最近手上这台 Jetson Orin NX 在往网盘传完一个大文件之后WiFi 直接掉线重连都连不上重启 NetworkManager 也没用。这个问题折腾了我一个周末翻日志、查电源、改配置总算把根因和可行的处理办法都摸了一遍。如果你也遇到“用网盘传大文件后 WiFi 消失”的情况尤其是在 Orin NX 这类嵌入式板子上这篇文章应该能帮你少走不少弯路。先说明一下这篇文章不是讲怎么修网盘客户端而是讲为什么一个纯应用层操作会把系统 WiFi 搞到“失联”以及从系统层面怎么排查、恢复和加固。内容基于 Jetson Orin NX 官方 Ubuntu 系统也就是 JetPack 环境不过大部分思路和命令在其他 Linux 板卡上也通用。1. 先搞明白传文件怎么把 WiFi “传没了”1.1 问题特征与常见误区我遇到的故障现象很典型用某网盘桌面客户端向云端上传一个约 20GB 的模型训练数据集上传进度接近 100% 时SSH 会话先卡住随后板卡 WiFi 断连。重新用有线连接查看执行nmcli发现 WiFi 被标记为“不可用”ip link里无线网卡的 STATE 是 DOWN/UNKNOWN而且扫描不到任何 SSID。很多人第一反应是“网盘服务把设备封了”或“路由器限制连接数”但大多数情况并不是。更常见的真相是长时间、高吞吐的上传任务把板卡自身的网络栈、内存、电源或散热拖垮最终导致 WiFi 模块假死或者驱动异常。可以把它理解为“把一辆小货车当重卡用”超载之后发动机先熄火而不是收费站不让过。1.2 为什么 Jetson Orin NX 更容易出现这种问题Jetson Orin NX 虽然算力很强但它的 WiFi 大多是 M.2 Key E 接口的模块比如 Intel AX2xx 系列或 Realtek 系列跟普通笔记本里的无线网卡不是一个体验。板卡通常只有 DC 供电散热方案也比较紧凑网卡模块紧挨着 CPU 和内存长时间满负荷上传时很容易出现模块温度过高、供电电压跌落、PCIe/USB 链路不稳定等情况。另一个关键因素是内存。Orin NX 在 JetPack 5.x/6.x 下默认会分一部分内存给 GPU系统可用内存本来就比标称值少。网盘桌面客户端上传大文件时通常会把文件切成块每个块都放进内存做校验和重传缓存再加上系统缓存页不断增长一旦内存压力过大内核的oom机制或网络协议栈异常就会让无线网卡变得极不稳定。简单说不是 WiFi “不想干活”是整机在极限状态下先崩了最弱的一环。2. 现场排查五分钟定位 WiFi 掉线根因2.1 先看网卡和系统状态出问题时不要马上重启先保留现场。通过有线网络或串口登录板卡依次执行这几条命令把状态记录下来nmcli radio nmcli dev status ip link iw dev rfkill list正常情况下nmcli dev status应该显示 wlan0 或 wlp 开头的设备状态为 connected/disconnected而不是 unavailable不可用。如果看到 unavailable通常不是连接配置问题而是射频被软件关闭或者驱动进入异常状态。这时再看一下rfkill list确认有没有“soft blocked / hard blocked”。再检查内存和负载free -h uptime sudo dmesg | tail -n 100dmesg是关键。WiFi 模块假死前通常会留下热警告、链路重启或者 PCIe 错误的记录。比如我这边看到的是ath10k_pci相关的 ce_report 错误如果模块是高通方案或者是iwlwifi报timeout。根据日志类型能快速判断到底是驱动层面、总线层面还是单纯电源/散热问题。2.2 用 dmesg 找内核日志里的线索如果日志里有这些关键词基本可以对号入座日志特征指向的问题thermal throttling/hot温度过高导致降频或模块关闭firmware error/timeout驱动与固件卡死需要复位PCIe link down/bus error无线网卡所在总线不稳定oom-killer内存不足系统开始杀进程wlan0: deauthenticated路由器主动断开或密钥协商超时这里有个容易忽略的点WiFi 掉线并不总是网卡本身的问题。如果上传期间dmesg里出现大量oom-killer或者kworker异常优先处理内存压力而不是回家把路由器换个遍。我见过不少人在这一步骤浪费时间最后发现是网盘客户端把 8GB 内存吃掉大半系统连基本网络服务都保不住。2.3 隔离测试是硬件还是系统为了区分“网卡彻底坏了”和“系统配置把网卡锁死”可以做两步隔离测试。第一步物理断开网盘上传任务等待 5 分钟然后执行sudo nmcli radio off sleep 3 sudo nmcli radio on sleep 5 nmcli dev wifi list如果 WiFi 能重新扫描到网络说明模块硬件没烧多半是系统层面的软锁或电源管理导致。第二步用有线网卡连接在完全不做任何上传的情况下长时间挂机看会不会再次掉线。如果不再掉线说明问题与高负载上传强相关接下来就可以针对电源、内存、网络管理三方面做处理。如果还是会掉线那就要查无线网卡本身的固件版本、天线接触和散热。3. 三大高频根因与对症解决方案3.1 电源/散热导致的 WiFi 模块假死Jetson Orin NX 的供电要求比较严格标称 7-20V DC 输入但很多第三方电源适配器在峰值负载时纹波很大或者电流余量不足。当网盘上传让 CPU、GPU、WiFi 模块同时高负载运行时瞬时电流可能突破适配器能力电压跌落直接让无线网卡复位。怎么判断用sudo jetson_clocks释放全部性能然后用tegrastats观察温度与功耗sudo tegrastats如果主芯片温度超过 85°CWiFi 模块又紧挨着主芯片基本可以认定是热环境问题。这种情况的解决方向有几种换成官方 19V 或符合功率要求的电源不要用手机充电头凑合。给机箱加一个主动散热风扇或者至少确保 WiFi 模块上方有气流。在/etc/rc.local或 systemd 服务里把 WiFi 模块的电源管理设置为关闭减少模块频繁降功耗带来的不稳定。补充一点很多 M.2 无线网卡默认开启了 IEEE 802.11 电源管理也就是所谓power save模式。嵌入式 Linux 下这种模式偶尔会让网卡在长时间高负载后进入低功耗状态而无法恢复。后面第 4 节我会给出关闭方法。3.2 内存耗尽与缓存堆积拖垮网络栈网盘客户端尤其是 Electron 套壳的桌面客户端在上传大文件时内存占用非常夸张。我在 Orin NX 8GB 版本上实测某网盘客户端上传 20GB 文件时RES常驻内存达到 4.2GB系统缓存还有 2GB 多剩下的可用内存不足 1GB。如果这时还在跑推理任务或训练脚本妥妥触发 OOM。在dmesg里看到类似Out of memory: Killed process 1234 (xxx)的记录说明系统已经动手杀进程了。网络管理器、DHCP 客户端、wpa_supplicant 这类服务优先级不高很可能被内核选中终止于是 WiFi 就“连接不上”了。解决思路很直接给网盘上传腾出内存空间或者限制客户端的缓存行为。上传前执行sync sudo sh -c echo 3 /proc/sys/vm/drop_caches清掉页缓存。给 Qt/Electron 客户端加--disable-dev-shm-usage或者设置环境变量限制内存但这类方法要看客户端支不支持。最稳妥的方案是改用命令行上传工具比如 rclone、aria2 配合网盘 WebDAV把并发数调低。也可以临时增加 swap 文件虽然不能根治但能避免 OOM 杀关键进程。增加 swap 的方法很简单sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile注意SD 卡或 eMMC 上开 swap 会影响寿命但如果用的是 NVMe SSD临时开 4GB swap 是很划算的保命手段。3.3 网盘客户端与网络管理服务互相打架第三种情况是软件层面的冲突。Jetson 官方系统默认用 NetworkManager 管理网络但网盘客户端有时会自己创建虚拟网卡、改路由表或者占用 DNS 端口。尤其是一些网盘客户端带有“加速上传”功能会在用户态做多线程并发甚至直接操作 socket 缓冲搞到一半把网络栈的 buffer 耗尽。看路由表和 socket 状态能发现端倪ip route ss -tunap | grep -i yourclientname如果路由表多了一条奇怪的0.0.0.0或192.168.x.x网关或者网盘客户端占用了大量 TIME_WAIT 连接基本就是它在搞事。这类问题的处理优先级是不要同时使用 NetworkManager 和 wicd/connman 等多个网络管理器容易出现配置互踩。网盘客户端里关闭“P2P 加速”或“多线程并发上传”选项。如果客户端不听话直接改用它支持的 WebDAV/FTP 接口绕开客户端。还有一种容易被忽略的情况网盘上传把路由器连接数打满导致 DHCP 续约失败。具体表现是 WiFi 关联正常但拿不到 IP或者获取到 IP 后上网几秒就断。这时需要看路由器的连接数限制通常把网盘客户端并发线程调低即可解决。4. 实战让 WiFi 在长时间上传下保持稳定4.1 紧急恢复连接的完整操作遇到 WiFi 断了连不上时按下面顺序操作能解决大部分软故障。先通过有线 SSH 登录依次执行sudo systemctl restart wpa_supplicant sudo nmcli radio off sleep 5 sudo nmcli radio on sleep 5 sudo nmcli dev wifi connect 你的SSID password 你的密码如果nmcli报错device not ready就强制重置网卡sudo ip link set wlan0 down sudo rmmod iwlwifi # 注意换成你的无线网卡驱动名 sudo modprobe iwlwifi sudo ip link set wlan0 up这里假设你的驱动是iwlwifi如果是 Realtek 或其他厂商先用lsmod | grep wifi或lsmod | grep 80211找到模块名。重置驱动后再执行一次nmcli dev wifi list能扫到网络基本就活了。最后一步是恢复 DHCP 状态sudo dhclient -r wlan0 sudo dhclient wlan0这几步做完90% 的连接不上问题都能恢复。如果还不活再考虑重启板卡。4.2 关闭 WiFi 省电减少掉线概率前面提到电源管理这里给出实际配置。NetworkManager 可以强制关闭 WiFi 省电模式sudo nmcli connection modify 你的SSID wifi.powersave 2也可以通过配置文件全局设置sudo nano /etc/NetworkManager/conf.d/wifi-powersave.conf写入[connection] wifi.powersave 2注意2是禁用省电3是启用省电。修改后重启 NetworkManagersudo systemctl restart NetworkManager很多 Intel WiFi 模块在省电开启时长时间挂机或高负载传文件后会出现延迟飙升、掉线无法重连。关闭省电虽然会增加一点点功耗但对嵌入式设备稳定性来说非常值得。另外可以通过iw直接查看当前电源管理状态iw dev wlan0 get power_save显示Power save: off就代表配置生效。4.3 用 rclone 替代桌面端网盘客户端我这里真心建议在 Jetson Orin NX 这种资源紧张的板卡上上传大文件不要用图形界面网盘客户端。无论哪个网盘桌面端都非常吃内存和 CPU。图形界面在远程无人值守的场景下也不好用SSH 断开就得靠 screen 或 tmux 续命本身也是坑。我现在的标准方案是 rclone tmux。先安装 rclone然后配置网盘的 WebDAV 或官方 APIsudo apt install rclone rclone config配置完成后用下面的命令上传限制并发数、限制带宽避免把板卡打满tmux new -s upload rclone copy /data/dataset remote:backup/dataset \ --transfers 2 \ --buffer-size 64M \ --drive-chunk-size 256M \ --progress--transfers 2的意思是同时只跑 2 个上传任务对 WiFi 和内存的压力都很小。--buffer-size 64M是每个任务的内存缓冲别设置太大。如果你的网盘是 WebDAV可以再加--low-level-retries 5和--retries 3断网后能自动重试不会一掉就崩。用 rclone 后系统内存占用从 4GB 降到了 200MB 以内WiFi 再没因为上传任务掉过线。这不是 rclone 本身多神奇而是它没有 Electron 那层壳也没有各种花哨的动画和自动更新模块资源占用完全透明可控。4.4 更新驱动与固件的正确姿势如果你的无线网卡在长时间高负载下频繁出问题可能是 JetPack 自带的内核驱动太老。Jetson 的 L4T 内核不是主线 Ubuntu 内核直接apt upgrade有时不会更新 WiFi 驱动。需要先确认无线网卡型号lspci | grep -i network lsusb | grep -i wireless确认型号后去网卡厂商或内核源码页面对应驱动版本。如果网卡是 Intel AX210/AX211可以先启用 Intel 官方的最新固件包把新固件放到/lib/firmware下。这个方法需要谨慎因为 Jetson 的驱动和固件必须与内核版本匹配乱放文件会导致网卡完全无法初始化。更安全的做法是通过 NVIDIA 的 SDK Manager 更新整个 JetPack 版本到最新发布版。最新版 L4T 往往包含对新一代 WiFi 模块的支持修复。但刷机有成本不是首选。我的建议是如果上面那些内存、电源、省电优化都做了WiFi 依然一传大文件就废再考虑刷机更新。不然的话稳定优先别折腾。更新固件后顺手检查无线网卡的天线有没有松。很多时候板卡在运输或长期使用后M.2 卡的两根天线接头会松动信号弱了之后长时间高负载传输就容易掉线跟驱动反而没关系。拧紧天线接头后同样的位置信号强度能从 -70dBm 回到 -50dBm整机稳定性会有明显改善。5. 常见问题速查与我的经验笔记5.1 问题排查速查表把这次排查过程整理成速查表下次再遇到可以少翻命令。现象优先检查快速处理WiFi 显示 unavailablerfkill list、nmcli radionmcli radio off on或重置驱动模块WiFi 能连上但无法上网路由表、DNS、DHCP 租约dhclient -r wlan0 dhclient wlan0传文件途中掉线且无法重连温度、电源、内存日志查看tegrastats清缓存检查供电掉线后几分钟自动恢复WiFi 省电模式设置wifi.powersave 2频繁 OOM 导致关键服务被杀内存占用、swap禁用页面缓存清理客户端添加 swap网盘客户端上传速度高时必掉线客户端并发设置换成 rclone限制--transfers这张表的内容是我实际踩坑后总结的不一定覆盖所有情况但至少能让你在 WiFi 断掉的时候不慌知道从哪里下手查。5.2 几个值得养成的习惯第一给 Jetson Orin NX 长期跑上传或下载任务时优先使用 USB 千兆有线网卡。这东西几十块钱比花几天排查 WiFi 不稳定划算太多。WiFi 适合做轻量连接和远程调试不适合长期高吞吐传输这跟板卡本身无关是 2.4G/5G 无线信道在嵌入式天线布局下的物理限制。第二定期清理网盘客户端的缓存目录。很多桌面客户端会把已上传的分块文件暂存在用户目录下上传完也不自动清掉日积月累会把 eMMC 或 SSD 空间占满。磁盘满了之后不仅 WiFi 连不上整机都会变得卡顿。第三上传大文件前先看一眼系统状态。养成一个习惯free -h df -h / uptime如果可用内存低于 1GB或者根分区满了先处理再传。我就吃过一次亏明明 WiFi 没问题因为磁盘满导致 wpa_supplicant 写不了日志间接让连接极不稳定查了半天才发现是日志把 100MB 的 /var 分区撑爆了。最后说一点个人体会。Jetson 平台是一个“麻雀虽小五脏俱全”的嵌入式电脑性能和功耗的平衡很微妙。很多 WiFi 问题看起来玄学归根结底是资源不够、电源不稳、配置不当这三件事。遇到问题不要先怀疑路由器先查日志再看硬件最后调配置。按这个顺序来你会发现绝大多数“连接不上 WiFi”的问题都能在十分钟内找到方向而不是盲目敲命令。