自建 RustDesk 进阶篇:把信令和中继藏进 443, 这是上一篇《自建 RustDesk 服务端的三个容器,到底各干什么?》的续集。建议先看完上一篇,理解 hbbs / hbbr / api 各自的角色,这篇会直接用到。上一篇结尾留了个尾巴:在跨境(比如大陆访问香港节点)场景里,RustDesk 的默认信令端口 21116 容易被链路上的设备做 RST 干扰,导致服务器一切正常、端口看着也通,但主控端就是连不上。当时给的应急办法是换端口(21116 → 31116 之类)。它的问题在于:如果干扰是按端口号识别的,换个端口能躲一阵;但如果是按协议特征(DPI) 识别的,换端口只是续命,过几天新端口照样被追上。这篇讲根治方案:把 hbbs 的信令和 hbbr 的中继,全部塞进 443 端口的 TLS 加密流量(WSS) 里。一、为什么 443 + WSS 能根治核心就一句话:让你的远控流量,在链路上看起来和访问一个普通 HTTPS 网站一模一样。躲开端口特征:对外只暴露 443,没有 21116、21117 这些一眼就知道是远控的"特征端口"。躲开协议特征(DPI):流量被 TLS 加密,中间设备拆不开,看不到里面的 RustDesk 握手,自然没法按协议指纹下手。顺带一个安全红利:全部走 443 之后,21114-21119 这些端口可以对公网全部关掉,攻击面大幅缩小。WSS = WebSocket over TLS。RustDesk 服务端本来就内置了 WebSocket 端口,我们要做的就是用 nginx 在 443 上做 TLS 终止,再把 WebSocket 转发给它们。二、用到哪些 WebSocket 端口RustDesk 服务端的两个核心服务,各自有一个专门的 WebSocket 端口:服务WebSocket 端口干什么hbbs(红娘)21118信令的 ws 通道hbbr(搬运工)21119中继的 ws 通道rustdesk-api(前台)21114网页后台 / API(普通 HTTP)这三个端口只需要 nginx 在本机访问,不用对公网开放。客户端永远只连 443。注意:如果你之前用了"换端口"的招(比如 hbbs 改成了 31116),上 WSS 之后可以撤回默认 21116。因为公网根本碰不到 21116 了,只有本机 nginx 去连它,换不换端口都无所谓。回归默认反而更省心。三、服务端:nginx 在 443 做 TLS 反代假设你的域名是 rustdesk.example.com,证书已经签好(下一节讲证书)。nginx 站点配置:server { listen 443 ssl http2; server_name rustdesk.example.com; ssl_certificate /etc/nginx/cert/rustdesk.example.com.pem; ssl_certificate_key /etc/nginx/cert/rustdesk.example.com.key; # 网页后台 + API(rustdesk-api 容器,本机 21114) location / { proxy_pass http://127.0.0.1:21114; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # ① hbbs 信令的 WebSocket(本机 21118) location /ws/id { proxy_pass http://127.0.0.1:21118; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_read_timeout 120s; } # ② hbbr 中继的 WebSocket(本机 21119) location /ws/relay { proxy_pass http://127.0.0.1:21119; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_read_timeout 120s; } }三个关键点:/ws/id → 21118、/ws/relay → 21119 是 RustDesk 约定好的路径,不能改名。WebSocket 必须带 Upgrade / Connection "upgrade" 这两个头,并且 proxy_http_version 1.1,否则握手升级不了。proxy_read_timeout 给长一点(120s 起),远控是长连接,超时太短会被掐断。如果你用宝塔面板,可以在站点的"反向代理"里分别加这几条;但 /ws/id、/ws/relay 的 WebSocket 头宝塔默认可能不带,建议直接编辑站点的 nginx 配置文件手动加,最稳。改完 nginx -t 测试无误后 nginx -s reload。四、证书域名解析到服务器后,用 Let's Encrypt 签一张免费证书即可。宝塔面板里"网站 → SSL → Let's Encrypt"一键申请最省事。命令行用 acme.sh 或 certbot 也行。证书路径填到上面 nginx 配置的 ssl_certificate / ssl_certificate_key 两行。WSS 必须有合法证书,自签证书客户端会拒连。这是和"裸 TCP"最大的不同——但也正是这张证书,让你的流量长得像正经网站。五、客户端:改成走 443 的 WSS这一步是 WSS 方案的前提,也是要特别说明的地方:客户端必须是支持 WebSocket 的版本/构建。 RustDesk 较新版本的服务端和客户端已原生支持 WebSocket 连接;如果你是自己编译的客户端(比如做了品牌定制),需要确认构建里开启了 WebSocket 能力。配置上,客户端的 ID 服务器 / 中继服务器 / API 服务器都指向你的 443 域名(rustdesk.example.com),Key 不变。WebSocket 启用后,客户端会自动走 wss://你的域名/ws/id 和 wss://你的域名/ws/relay,全程 443。各版本开启 WebSocket 的具体开关可能不同(有的是网络设置里的选项,有的需要构建参数)。落地前请以你所用版本/构建的实际配置为准,先用一台客户端验证能连通,再全量下发。六、收尾大杀器:只留 443,关掉所有远控端口确认 WSS 能正常远控之后,就可以做这件最爽的事了:把 21114-21119 对公网全部关闭,防火墙只留 443(和 SSH)。按 RustDesk 官方说法,当客户端全部走 WebSocket 时,服务端可以关掉 21114-21119,只保留 443 一个对外端口。此时:对外扫描你的服务器,只看到一个 443,和千千万万个网站没区别;链路上的设备抓不到远控特征,也就没法按端口或协议来封;攻击面从一排端口缩成一个,安全性也上来了。防火墙(云厂商安全组 + 服务器本地,两层都要)最终只需要:协议端口说明TCP443全部远控流量(WSS)+ 网页后台TCP你的 SSH 端口远程管理21114-21119 那一排,可以从两层防火墙里全部删掉。七、和"换端口"方案怎么选 换端口443 WSS落地难度极低(改配置 + 放行端口)中(要证书 + nginx + 客户端支持 ws)抗封能力续命,可能被重新识别根治,看起来就是普通 HTTPS对外端口仍暴露一排远控端口只留 443适合场景临时救急、先恢复使用长期稳定运营实战建议:出问题先用换端口快速恢复业务,腾出手再上 WSS 做长期方案。 两步走,既不耽误用,又能根治。小结WSS 方案的本质,是把"一眼就能被认出来的远控流量",伪装成"满大街都是的 HTTPS 流量"。服务端:nginx 在 443 做 TLS,/ws/id 转 21118、/ws/relay 转 21119;客户端:用支持 WebSocket 的构建,指向 443 域名;收尾:关掉 21114-21119,只留 443。

自建 RustDesk 服务端的三个容器，到底各干什么？一篇大白话讲清楚 自己搭过 RustDesk 服务端的人,大概都被那一长串 docker run 劝退过:hbbs、hbbr、还有一个第三方的 rustdesk-api,三个容器一堆端口,看着头大。这篇就用大白话把它们讲明白。先打个比方建立整体印象:RustDesk 干的事,本质就是 让两台电脑隔着互联网"牵手"。三个容器分别扮演:红娘、搬运工、前台管理员。记住这三个角色,后面就全通了。一、rustdesk-hbbs —— 红娘(信令服务器)hbbs -r 你的域名:21117它负责 牵线搭桥。所有客户端开机后,都会先到红娘这里 报到登记:"我是 ID 12345,我现在在线,我的网络地址是 xxx"。当你想远程某台电脑时,你先找红娘说一句"我要连 67890",红娘就把 双方的网络地址互相告知,撮合两台电脑尝试 直接牵手(P2P 打洞)。它用到三个端口——而且你只需要指定主端口,另外两个是 hbbs 自动派生出来的:端口协议用途怎么来的21116TCP+UDP主信令:登记报到、发起连接请求你指定的主端口21115TCPNAT 类型测试(判断你的网络好不好打洞)主端口 减 121118TCPWebSocket,给网页客户端用主端口 加 2小记:hbbs 可以理解成 Handbook bridge server——牵线的那个。二、rustdesk-hbbr —— 搬运工(中继服务器)hbbr红娘撮合之后,如果两台电脑能 直接牵手(P2P 成功),数据就走直连,搬运工不参与,速度最快。但现实里,双方常常都躲在路由器后面(NAT),握不上手。 这时候就轮到搬运工出场:两台电脑各自把数据交给它,由它在中间 转发画面、键鼠、文件。走中继时,所有流量都从它身上过,所以 它是最吃带宽的一个。如果你的主控和被控分布在不同地区、还经常打洞失败,那这台搬运工的出口带宽就是体验好坏的关键。端口协议用途21117TCP中继转发数据(屏幕 / 键鼠 / 文件都走这)21119TCPWebSocket 中继,网页客户端用小记:hbbr = Handbook bridge relay——搬东西的那个。红娘那条 -r 你的域名:21117 参数,就是让红娘在撮合时顺便告诉客户端:"打洞失败的话,去这个地址找搬运工。"三、rustdesk-api —— 前台管理员(Web 管理后台)lejianwen/rustdesk-api:...注意:这个容器不是 RustDesk 官方的,是社区做的增强后台。前面两个(红娘、搬运工)才是干活的核心,光有它俩,RustDesk 就已经能正常用了。这个 api 属于 锦上添花,它给你提供:网页管理后台(/_admin/):查看哪些设备在线、管理用户、地址簿、权限网页客户端(/webclient/):不装软件,浏览器里直接发起远程API 接口:给客户端下发配置、登录鉴权等端口用途21114api 服务的 HTTP 端口它靠几个环境变量,知道红娘和搬运工分别在哪:ID_SERVER = 127.0.0.1:21116 # 红娘在本机 21116 RELAY_SERVER = 127.0.0.1:21117 # 搬运工在本机 21117 SIGNAL_SERVER = 127.0.0.1:21115 # NAT 测试端口如果你改了 hbbs 的主端口,这几个值要 跟着一起改,否则后台和真正干活的容器就对不上号了。把它们串起来看你(主控) 对方(被控) │ │ │ ①「我要连对方」 ① 早就登记过 │ └──────────► 红娘 hbbs (21116) ◄─────────────┘ │ ② 撮合,互告地址 │ ┌─────────────┴─────────────┐ ▼ ▼ 能直连?──是──► P2P 直连,搬运工不参与(最快) │ 否 ▼ 搬运工 hbbr (21117) 在中间转发画面 / 键鼠 / 文件一句话总结容器角色干什么核心端口缺了会怎样rustdesk-hbbs红娘登记、撮合、打洞21116不可缺,没它谁都连不上rustdesk-hbbr搬运工打洞失败时中继转发21117不可缺,没它打洞失败就彻底连不上rustdesk-api前台管理员网页后台 / 网页客户端 / API21114可缺,只是没有后台,裸用照样行hbbs 牵线、hbbr 搬货、api 管后台。 前两个是骨架,第三个是装修。附录:一键部署脚本(可直接套用)下面这套脚本把三个容器一次性拉起来。用之前只需要改一处——把 RD_DOMAIN 换成你自己的域名:#!/usr/bin/env bash # RustDesk 服务端一键部署脚本(hbbs + hbbr + api) # 用法:改好 RD_DOMAIN,保存为 deploy.sh,然后 bash deploy.sh RD_DOMAIN="rustdesk.example.com" # ← 改成你自己的域名 RD_DIR="/home/$USER/dockerfile/rustdesk" # 数据存放目录,可自定义 # 清理旧容器(首次部署没有也不会报错) docker rm -f rustdesk-hbbs rustdesk-hbbr rustdesk-api 2>/dev/null # 准备数据目录 mkdir -p "$RD_DIR"/{data,api} # ① 红娘:hbbs 信令服务器 docker run -d \ --name rustdesk-hbbs \ --restart always \ --network host \ -v "$RD_DIR/data":/root \ rustdesk/rustdesk-server:1.1.15 \ hbbs -r ${RD_DOMAIN}:21117 # ② 搬运工:hbbr 中继服务器 docker run -d \ --name rustdesk-hbbr \ --restart always \ --network host \ -v "$RD_DIR/data":/root \ rustdesk/rustdesk-server:1.1.15 \ hbbr # ③ 前台管理员:rustdesk-api 网页后台(第三方,可选) docker run -d \ --name rustdesk-api \ --restart always \ --network host \ -e TZ=Asia/Shanghai \ -e RUSTDESK_API_LANG=zh-CN \ -e RUSTDESK_API_APP_WEB_CLIENT=1 \ -e RUSTDESK_API_RUSTDESK_ID_SERVER=127.0.0.1:21116 \ -e RUSTDESK_API_RUSTDESK_RELAY_SERVER=127.0.0.1:21117 \ -e RUSTDESK_API_RUSTDESK_API_SERVER=https://${RD_DOMAIN} \ -e RUSTDESK_API_RUSTDESK_SIGNAL_SERVER=127.0.0.1:21115 \ -e RUSTDESK_API_APP_REGISTER=false \ -v "$RD_DIR/api":/app/data \ -v "$RD_DIR/data":/app/conf/data \ lejianwen/rustdesk-api:v2.7 # 等待启动,打印关键信息 sleep 5 echo "=== 部署完成 ===" docker ps | grep rustdesk echo "" echo "管理后台: https://${RD_DOMAIN}/_admin/" echo "网页客户端: https://${RD_DOMAIN}/webclient" echo "ID 服务器: ${RD_DOMAIN}:21116" echo "中继服务器: ${RD_DOMAIN}:21117" echo "公钥(Key): $(cat "$RD_DIR/data/id_ed25519.pub" 2>/dev/null || echo '稍等几秒再查看')" echo "管理员密码: $(docker logs rustdesk-api 2>/dev/null | grep -i 'Admin Password Is:' | tail -1 | sed 's/.*Admin Password Is: //')"部署完别忘了 放行端口(云厂商安全组 + 服务器本地防火墙,两层都要开):协议端口说明TCP21114-21119api / hbbs / hbbr 全套UDP21116hbbs 信令(必须,容易漏)客户端配置时填三样:ID 服务器 = 你的域名:21116、中继服务器 = 你的域名:21117、Key = 上面打印出来的公钥内容。脚本里用的是默认端口 21116。如果你的网络环境需要换端口(见下一节),把 hbbs 那行加上 -p 新端口,同时改 api 的 ID_SERVER / SIGNAL_SERVER,并放行新端口对应的三个口。一点实战补充:为什么有人把 21116 改成别的端口21116 是 RustDesk 的默认信令端口,也正因为太出名,成了被重点识别的"特征端口"。在一些跨境(比如大陆访问香港节点)的场景里,会遇到一个很迷惑的现象:服务器、防火墙、Key、配置全都正确telnet 端口看着也通但只要真正发起远程,主控端就连不上这种情况往往不是服务器的锅,而是 链路上对"特定 IP + 21116 端口"做了 RST 干扰。一个常见的应急办法,就是把 hbbs 的主端口从 21116 挪到一个冷门高位端口(比如 31116),配置同步下发,很多时候就能立刻恢复。记得改端口要三处一起改:hbbs 的 -p 参数、api 的环境变量、防火墙放行新端口(派生的三个端口都要放)——而且云厂商安全组和服务器本地防火墙是两层,都得开。不过换端口属于"续命"而非"根治",更稳的长期方案是把信令和中继套进 443 的 TLS/WSS 流量里,让链路层抓不到特征。这就是另一篇的故事了。

禁用 Windows 10 自动更新 — 完整踩坑记录 操作环境：Windows 10，PowerShell（管理员权限） 目标：彻底、永久禁止系统自动更新一、背景Windows 10 的自动更新机制非常顽固，微软在多个层面都做了保护：服务层：wuauserv（Windows Update）+ UsoSvc（Update Orchestrator）策略层：注册表 AU 策略计划任务层：\Microsoft\Windows\UpdateOrchestrator\* 下十余个任务权限保护：部分计划任务文件归属 TrustedInstaller，普通管理员无法直接修改仅禁用服务是不够的，Win10 会通过计划任务自动把服务重新拉起。二、踩坑过程第一次尝试（只禁服务 + 注册表）Stop-Service wuauserv -Force Set-Service wuauserv -StartupType Disabled Set-Service UsoSvc -StartupType Disabled Stop-Service UsoSvc -Force reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoUpdate /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v AUOptions /t REG_DWORD /d 1 /f问题：未处理计划任务，系统会通过 UpdateOrchestrator 定时任务重新启用服务并触发更新。第二次尝试（追加禁用计划任务）Get-ScheduledTask -TaskPath "\Microsoft\Windows\UpdateOrchestrator\*" | Disable-ScheduledTask报错：Disable-ScheduledTask : 拒绝访问。 HRESULT 0x80070005原因：这些计划任务文件（位于 C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator\）的所有者是 TrustedInstaller，即使管理员也无写入权限。第三次尝试（夺权后再禁用）✅ 成功思路：对每个任务文件先 takeown 夺取所有权，再 icacls 授权，最后执行 Disable-ScheduledTask。Get-ScheduledTask -TaskPath "\Microsoft\Windows\UpdateOrchestrator\*" | ForEach-Object { $path = "C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator\$($_.TaskName)" takeown /f $path /a icacls $path /grant Administrators:F Disable-ScheduledTask -TaskName $_.TaskName -TaskPath $_.TaskPath }结果：全部 13 个任务均成功禁用（State: Disabled）。三、最终完整一行命令⚠️ 需以管理员身份运行 PowerShellStop-Service wuauserv -Force; Set-Service wuauserv -StartupType Disabled; Set-Service UsoSvc -StartupType Disabled; Stop-Service UsoSvc -Force; reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoUpdate /t REG_DWORD /d 1 /f; reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v AUOptions /t REG_DWORD /d 1 /f; Get-ScheduledTask -TaskPath "\Microsoft\Windows\UpdateOrchestrator\*" | ForEach-Object { $path = "C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator\$($_.TaskName)"; takeown /f $path /a; icacls $path /grant Administrators:F; Disable-ScheduledTask -TaskName $_.TaskName -TaskPath $_.TaskPath }四、三层封锁说明层级操作说明服务层禁用 wuauserv + UsoSvc停止并设为 Disabled，阻止开机自启策略层写注册表 AU 策略NoAutoUpdate=1，AUOptions=1，策略级别覆盖用户设置计划任务层夺权并禁用全部 UpdateOrchestrator 任务防止任务重新拉起服务五、被禁用的计划任务清单任务名作用Reboot_AC插电时重启安装更新Reboot_Battery电池模式重启安装更新Report policies上报策略信息Schedule Maintenance Work计划维护工作Schedule Scan计划扫描更新Schedule Scan Static Task静态扫描任务Schedule Wake To Work唤醒执行更新Schedule Work计划更新工作Start Oobe Expedite WorkOOBE 加急更新StartOobeAppsScanAfterUpdate更新后扫描应用StartOobeAppsScan_LicenseAccepted许可接受后扫描UpdateModelTask更新模型任务USO_UxBroker更新界面代理六、恢复方法（如需重新开启更新）Set-Service wuauserv -StartupType Manual Start-Service wuauserv Set-Service UsoSvc -StartupType Manual Start-Service UsoSvc Get-ScheduledTask -TaskPath "\Microsoft\Windows\UpdateOrchestrator\*" | Enable-ScheduledTask reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /f记录时间：2026-05-18

uni.getSystemInfoSync 全量信息解析 📱 uni.getSystemInfoSync 全量信息解析（iPhone 12 + iOS 18.5 示例）在开发基于 UniApp 的移动应用时，获取设备信息对于 UI 适配、安全区域计算、调试优化 至关重要。本文将基于一份真实的系统信息（以 iPhone 12 为例），完整解析 uni.getSystemInfoSync() 返回的数据结构，并提供适配建议。注：所有敏感信息如设备ID、AppID 等均已脱敏或替换。📦 基础信息字段示例值含义brand / deviceBrandapple设备品牌model / deviceModeliPhone 12设备型号platformios系统平台system / osVersioniOS 18.5系统版本language / osLanguagezh-Hans-HK当前系统语言（简体中文-香港）deviceTypephone设备类型📐 屏幕 & 像素信息字段示例值含义pixelRatio / devicePixelRatio3物理像素 / 逻辑像素比screenWidth390 px屏幕宽度screenHeight844 px屏幕高度windowWidth390 px可视区域宽度windowHeight844 px可视区域高度statusBarHeight47 px状态栏高度（刘海高度）🔒 安全区域信息安全区域对于适配刘海屏和底部 Home Indicator 非常重要。"safeArea": { "top": 47, "bottom": 810, "left": 0, "right": 390, "width": 390, "height": 763 }, "safeAreaInsets": { "top": 47, "bottom": 34, "left": 0, "right": 0 }字段示例值含义safeAreaInsets.top47 px顶部安全区（通常是状态栏）safeAreaInsets.bottom34 px底部安全区（通常是 Home Indicator 区域）safeArea.height763 px内容区高度（去除安全边距）🧱 App & UniApp 信息字段示例值含义appNameMyApp应用名称（已脱敏）appId__UNI__xxxxxxx应用 ID（已脱敏）appVersion14.75用户可见版本appVersionCode1475内部版本号（用于版本比较）appWgtVersion4.3.54资源版本（wgt 包）uniPlatformapp当前平台uniCompileVersion4.64编译时使用的 HBuilderX 版本uniRuntimeVersion4.75App 运行时版本browserNamewkwebviewiOS 内核类型browserVersion18.5WebView 版本（与系统一致）uaMozilla/5.0...uni-app浏览器 UserAgent（已截断）🧪 实际使用建议✅ 状态栏高度使用：padding-top: var(--status-bar-height); // 适配刘海屏✅ Bottom 安全区适配：padding-bottom: env(safe-area-inset-bottom); // 适配 Home Indicator✅ JS 动态计算 padding：const system = uni.getSystemInfoSync(); const paddingTop = system.statusBarHeight + 44; // 状态栏 + 自定义导航栏 const paddingBottom = system.safeAreaInsets.bottom + 55; // Home Indicator + 底部 tab🎯 调试辅助（推荐实践）在开发过程中你可以引入一个 浮动调试按钮，点击后显示当前系统信息及安全区计算值，便于测试不同设备的实际效果。例如：minHeight: 100vhpaddingTop: calc(var(--status-bar-height) + 44px)paddingBottom: calc(env(safe-area-inset-bottom) + 55px)🧾 总结本文详细解析了 uni.getSystemInfoSync() 的所有关键字段及含义，尤其针对 iPhone 12 的刘海屏、安全区域、底部指示器做了说明。了解这些参数，可以帮助我们开发时更好地进行：UI 适配页面布局计算自定义导航栏和底部栏浮动调试工具实现

Linux 命令行连接 Wi-Fi（适用于 PVE、Debian、Ubuntu） 最简单、最快速的方式只需一行命令：nmcli device wifi connect "Long" password "xiyang" iface wlo1✅ 说明：Long 是 Wi-Fi 名称（SSID）xiyang 是密码wlo1 是你的无线网卡名称，可用 ip link 或 nmcli device 查看📶 查看当前无线接口和状态nmcli device status🔍 查看可用 Wi-Fi 热点nmcli device wifi list📂 管理连接配置列出已保存的连接：nmcli connection show设置开机自动连接（通常默认已启用）：nmcli connection modify "Long" connection.autoconnect yes删除旧配置（如需重连）：nmcli connection delete "Long"⚙️ 设置静态 IP（可选）nmcli connection modify "Long" ipv4.method manual \ ipv4.addresses 192.168.1.100/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns "8.8.8.8 1.1.1.1"🚀 开机自动连接（脚本方案）创建脚本 /usr/local/bin/wifi-connect.sh：#!/bin/bash nmcli device wifi connect "Long" password "xiyang" iface wlo1加执行权限：chmod +x /usr/local/bin/wifi-connect.sh添加 systemd 服务实现开机连接（略）。📝 结语适用于没有桌面环境的 Linux 系统，如 PVE、Debian、服务器等环境下轻松连接 Wi-Fi。只需 nmcli，不必使用图形界面！