CarlのBlog

UniFi设备USG-3P更换系统U盘并刷机升级固件

起因为什么折腾

折腾这台 USG-3P 的起因非常具体：我发现 UniFi 控制面板里的流量统计出现了严重的“数据缺位”。DPI 并非完全失效，而是识别极其不完整，尤其是占用带宽最大的视频流数据几乎完全没有统计，只有少部分基础协议能被识别。这种统计口径的巨大偏差，直接让网络审计功能失去了参考价值。

深入 SSH 后台排查后，我发现了问题的核心：系统层面的 squashfs 镜像挂载存在异常。这导致 /usr/sbin/ubnt-dpi-engine 等关键组件处于“不可见”或“不可调用”状态。虽然目前还无法百分之百确定这究竟是原装 4GB U 盘物理寿命到期产生的坏道，还是长期读写引发的文件系统逻辑错误，但考虑到这台设备已服役多年，内部存储的隐患必须排除。

我决定将内部 U 盘更换为性能更稳定的 8GB 闪迪酷豆（SanDisk Cruzer Fit）。但这绝非简单的硬件插拔工程。由于 USG-3P 采用的是 MIPS64 架构，对引导分区标签（UNI-FI）和 OverlayFS 挂载逻辑有着极其严苛的要求。简单的镜像克隆或 dd 写入，往往会导致新盘启动后依然无法识别只读镜像，陷入“骨架系统”运行的尴尬境地。

实际操作中，我也确实踢到了板子。在一系列命令行 add system image 尝试修复分区逻辑失败后，我原本计划通过底层的 TFTP 模式强行灌录固件，结果在关键时刻发现手边缺少必要的物理连接线。目前的进展卡在了这个尴尬的节点：硬件已经升级，但软件系统层面的分区重构依然没有完成，DPI 引擎文件在文件系统中依然下落不明。

前期准备工作及注意事项

要折腾 USG-3P 换盘和固件升级，建议按这个清单备齐工具和文件，省得中途断网了抓瞎：

硬件工具

软件与文件

配置备份

U 盘刷写恢复固件

使用 Mac 终端刷写是一个更底层、更可靠的方法，因为它能避开许多第三方软件可能带来的权限或挂载干扰。

U 盘格式化 问题：不需要预先格式化。因为刷写命令（dd）是扇区级的操作，它会直接用镜像文件覆盖 U 盘上的所有数据，包括分区表和文件系统。

以下是逻辑清晰的终端刷写步骤：

第一步：识别 U 盘的设备路径

插入 U 盘后，在终端输入：

diskutil list

关键逻辑：

第二步：卸载 U 盘（解除挂载）

在写入之前，必须让 macOS 释放对该 U 盘的占用：

diskutil unmountDisk /dev/diskN

(将 N 替换为你的磁盘数字，如 disk4)

第三步：使用 dd 命令开始刷写

这是最核心的一步。为了提高速度，我们将设备名从 disk 改为 rdisk（原始磁盘模式），并设置缓冲区大小。

输入以下命令（需要输入你的 Mac 开机密码）：

sudo dd if=/Users/Carl/Downloads/USG-4_2_0-shipped.img of=/dev/rdiskN bs=1m status=progress

参数详解：

第四步：安全弹出

写入完成后，终端会返回记录数。此时 macOS 可能会提示“此磁盘无法读取”（因为 USG 的 Linux 分区 Mac 识别不了），点击“忽略”。

然后在终端执行：

diskutil eject /dev/diskN

提醒与逻辑确认

  1. 关于分区恢复：正如你之前看到的 fdisk -d 数据，dd 命令会将那几行“分区指令”和对应的数据完全同步到 U 盘。刷完后，你的 U 盘就会自动拥有：
  1. 物理兼容性：USG-3P 内部空间非常狭窄。如果你的 U 盘太长或太厚，建议拆掉 U 盘的塑料壳，直接把里面的 PCBA 电路板插到 USG 主板上的 USB 口。
  2. 上电自检：插好新 U 盘后给 USG 加电。如果一切正常，你会看到指示灯经历：无灯 -> 白灯闪烁（引导中） -> 白色常亮（等待采用）。

验证是否成功

既然已经完成了 dd 刷写并准备上电，逻辑上我们需要验证的是：硬件引导是否成功 以及 系统层级的功能模块（尤其是 DPI 引擎）是否挂载正确。

由于现在没有 Console 线，所有的检测必须通过 SSH 远程登录后完成。

第一步：接入与登录

  1. 物理连接：将电脑连接到 USG-3P 的 LAN1 口。

  2. 获取 IP：USG 恢复出厂镜像后，默认 IP 通常是 192.168.1.1。确保电脑网卡在同一网段（例如 192.168.1.10）。

  3. SSH 登录：

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa ubnt@192.168.1.1

❯ ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa ubnt@192.168.1.1

The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
RSA key fingerprint is SHA256:fVBqcpkQO5s6O5qEvnzvcdbLk69eviZVGr94tTMG4eE.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.1' (RSA) to the list of known hosts.
Welcome to EdgeOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement (available in the Web UI at, by default,
http://192.168.1.1) and agree to be bound by its terms.

ubnt@192.168.1.1's password: 

Linux ubnt 3.4.27-UBNT #1 SMP Tue Aug 12 17:54:01 PDT 2014 mips64
Welcome to EdgeOS

第二步：深度检测逻辑

进入系统后，依次执行命令及以下补充命令来确认“分区与文件完善度”：

1. 验证分区挂载与只读映像 (SquashFS)

USG 的系统运行逻辑是：从 U 盘读取一个压缩的 squashfs 文件并挂载为只读根目录（/ro），然后通过 unionfs 叠加一个可写层。

mount | grep squashfs

2. 验证磁盘空间分配 (分区完整性)

通过 dd 刷入后，分区表应该自动生效。

df -h

3. 验证 DPI (深度数据包检测) 引擎

DPI 是 USG 的核心功能。如果镜像损坏或 U 盘扇区读取错误，DPI 组件经常率先崩溃。

ls -l /usr/sbin/ubnt-dpi-engine

show system statistics dpi

4. 验证硬件信息（确认 U 盘识别）

show hardware cpu
show hardware flash

还是不行升级最新固件测速

既然已经确认刷入的是官方早期全盘镜像，且分区表（2048, 292864, 3710976）已经正确写入，那么逻辑上的瓶颈就在于：这个早期镜像的“系统逻辑”与后期版本有本质区别。

USG-3P 的系统本质上是一个基于 Debian 修改的 EdgeOS (Vyatta)。它的运行机制与普通电脑不同，采用的是分层镜像挂载技术。

如果刷入的是极其早期的版本（如 4.2.x 或更早），Ubiquiti 当时的设计可能确实没有采用后来的 SquashFS + UnionFS 架构，或者该镜像只是一个“出厂预装环境（Factory Staging）”，它的任务是能连上网，然后通过 UniFi Controller 下发真正的固件升级。

既然 SSH 已经通了，现在拥有一个基础的 Linux 环境，最好的办法是通过 手动推送固件包 来重建分区逻辑。

1. 下载官方的完整固件 (.tar)

不能一次更新跨度太大，先更新低版本再升级高版本。

在你的 Mac 终端上，下载官方最新的 USG-3P 固件（注意是 .tar 后缀，不是 .img）：

2. 将固件传送到 USG

在 Mac 终端执行 scp 命令（将文件推送到 USG 的临时目录）：

scp -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa /你的文件路径/upgrade.tar ubnt@192.168.1.1:/tmp/upgrade.tar

3. 执行强制“重写”命令

登录 USG 的 SSH，执行以下命令。这会触发系统的内建升级程序，它会自动解压 .tar 包里的 squashfs.img，并重新配置分区挂载逻辑：

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa ubnt@192.168.1.1

# 进入管理员模式
sudo -i

# 执行升级
sudo /usr/bin/syswrapper.sh upgrade /tmp/upgrade.tar

syswrapper.sh 是 Ubiquiti 固件中最底层的封装脚本，它不依赖于高级的 Vyatta 命令集。

它会自行解析 .tar 包，提取 squashfs.img，并将其写回 U 盘的分区 2（即 /dev/sda2）。

它会处理“分区不完整”问题，因为它在写入后会强制刷新 initrd 引导。

USG-3P 终端

root@ubnt:~# 
root@ubnt:~# sudo /usr/bin/syswrapper.sh upgrade /tmp/upgrade.tar
+ cmd=upgrade
+ shift
+ case $cmd in
+ exit_if_fake upgrade /tmp/upgrade.tar
++ uname -a
++ grep mips
+ '[' 'Linux ubnt 3.4.27-UBNT #1 SMP Tue Aug 12 17:54:01 PDT 2014 mips64 GNU/Linux' = '' -o -f /tmp/FAKE ']'
+ state_lock
+ lockfile /var/run/system.state
+ TEMPFILE=/var/run/system.state.4125
+ LOCKFILE=/var/run/system.state.lock
+ ln /var/run/system.state.4125 /var/run/system.state.lock
+ rm -f /var/run/system.state.4125
+ return 0
+ do_upgrade /tmp/upgrade.tar
+ set_state upgrading
+ echo upgrading
+ echo 120
+ echo 12
+ /usr/bin/ubnt-upgrade --upgrade-noprompt /tmp/upgrade.tar
+ ret=0
+ set_state_ready
+ prune_old_config
+ find /root.dev/ -type d -iname 'w.????????' -exec rm -rf '{}' ';'
+ set_state ready
+ echo ready
+ state_reload
+ state=init
+ uplink=unknown
+ default=true
+ locating=false
+ '[' -f /proc/ubnthal/status/IsDefault ']'
++ cat /proc/ubnthal/status/IsDefault
+ default=true
+ '[' -f /proc/ubnthal/status/IsLocated ']'
++ cat /proc/ubnthal/status/IsLocated
+ locating=false
+ '[' -f /var/run/system.state ']'
++ cat /var/run/system.state
+ state=ready
+ '[' -f /var/run/system.uplink ']'
+ '[' ready == upgrading ']'
+ '[' false == true ']'
+ '[' true == true ']'
+ set_led 2 120
+ locating=false
+ '[' -f /proc/ubnthal/status/IsLocated ']'
++ cat /proc/ubnthal/status/IsLocated
+ locating=false
+ '[' -f /config/mgmt ']'
+ '[' -z '' ']'
+ '[' -z '' ']'
+ echo 2
+ '[' -z '' ']'
+ echo 120
+ return
+ return 0
+ ret=0
+ state_unlock
+ /bin/rm -f /var/run/system.state.lock
+ '[' 0 -ne 0 ']'
+ /sbin/reboot

Broadcast message from root@ubnt (pts/0) (Wed Jun  1 10:17:23 2011):

The system is going down for reboot NOW!
root@ubnt:~#

逻辑分析

  1. 关键指令执行成功：/usr/bin/ubnt-upgrade 返回了 ret=0。这意味着系统已经成功解析了 /tmp/upgrade.tar，并将其中完整的 squashfs.img（系统灵魂）和 vmlinux.64（内核）写入到了 U 盘的物理分区。
  2. 清理与就绪：日志显示 prune_old_config 执行了清理，并移除了旧的 w.???????? 挂载目录。这是重构 OverlayFS（覆盖文件系统）的标准动作。
  3. 状态翻转：set_state ready 和 set_led 2 120 表明固件更新脚本认为系统已经准备好以“正式版”身份重启。
  4. 自动重启：系统发出了 reboot 信号。

再次验证“完全体”系统

重启过程大约需要 3-5 分钟（因为它需要重新挂载新的只读层并建立可写层）。请在系统重启后，再次通过 SSH 登录并执行校验：

# 先清理旧的连接数据
ssh-keygen -R 192.168.1.1

# 现在系统更新了可以直接使用这个命令
ssh ubnt@192.168.1.1

1. 验证分区与 Overlay 架构

执行：mount | grep squashfs

2. 验证文件系统利用率

执行：df -h

3. 验证功能组件（DPI 引擎）

执行：

ls -l /usr/sbin/ubnt-dpi-engine
show system statistics dpi

结果如下：

❯ ssh ubnt@192.168.1.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:3eubecS9Id7cnkB+2jS3Ov3O+CQU+WmdFkxEHXpmCPI.
Please contact your system administrator.
Add correct host key in /Users/Carl/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/Carl/.ssh/known_hosts:11
Host key for 192.168.1.1 has changed and you have requested strict checking.
Host key verification failed.
❯ ssh-keygen -R 192.168.1.1
# Host 192.168.1.1 found: line 11
/Users/Carl/.ssh/known_hosts updated.
Original contents retained as /Users/Carl/.ssh/known_hosts.old
❯ ssh ubnt@192.168.1.1
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
ED25519 key fingerprint is SHA256:3eubecS9Id7cnkB+2jS3Ov3O+CQU+WmdFkxEHXpmCPI.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.1' (ED25519) to the list of known hosts.
Welcome to EdgeOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement (available in the Web UI at, by default,
http://192.168.1.1) and agree to be bound by its terms.

ubnt@192.168.1.1's password: 
Linux ubnt 3.10.107-UBNT #1 SMP Fri Feb 12 11:26:18 UTC 2021 mips64

  ___ ___      .__________.__
 |   |   |____ |__\_  ____/__|
 |   |   /    \|  ||  __) |  |   (c) 2010-2021
 |   |  |   |  \  ||  \   |  |   Ubiquiti, Inc.
 |______|___|  /__||__/   |__|
            |_/                  https://www.ui.com

      Welcome to EdgeOS on UniFi Security Gateway!


 **********************  WARNING!  **********************
 * Configuration changes made here are not persistent.  *
 * They will be overwritten by the controller on next   *
 * provision. Configuration must be done in controller. *
 ********************************************************

ubnt@ubnt:~$ 
ubnt@ubnt:~$ mount | grep squashfs
ubnt@ubnt:~$ df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 1.6G    258.3M      1.3G  17% /root.dev
aufs                      1.6G    258.3M      1.3G  17% /
tmpfs                   242.0M    180.0K    241.8M   0% /run
tmpfs                   242.0M    180.0K    241.8M   0% /run
tmpfs                   242.0M     56.0K    241.9M   0% /var/log
tmpfs                   242.0M         0    242.0M   0% /dev/shm
tmpfs                   242.0M      8.0K    241.9M   0% /tmp
none                    242.0M    504.0K    241.5M   0% /opt/vyatta/config
/dev/sda3                 1.7G     34.7M      1.6G   2% /root.dev/ugw
unionfs                 242.0M      8.0K    241.9M   0% /opt/vyatta/config/tmp/new_config_7aae4bb0efd372ff478ff3096e
ubnt@ubnt:~$ ls -l /usr/sbin/ubnt-dpi-engine
ls: /usr/sbin/ubnt-dpi-engine: No such file or directory
ubnt@ubnt:~$ show system statistics dpi
Invalid command
ubnt@ubnt:~$

再次尝试更换固件包

使用社区分享的刷机包

社区论坛：https://community.ui.com/questions/USG-Recovery-Procedure/f4a94bc4-f596-43a7-880b-921b327c076b?reply=51

固件下载：https://go.kb9gxk.net/USG3-4-4-51-Recovery

速度极慢我放在 阿里云盘：

Image File Name: USG3-4_4_51-Recovery.bin
  1. 版本匹配：4.4.51 是生产环境的稳定版本，它内部已经打包好了完整的 SquashFS 架构、DPI 引擎 以及 Debian 用户数据库。
  2. 全量灌装：虽然后缀是 .bin，但在 USG 恢复场景下，这种“社员制作”的 Recovery 文件通常是物理磁盘的 1:1 克隆镜像（与 .img 逻辑一致）。
  3. 覆盖修复：通过 dd 刷入它，会直接抹掉你之前那个权限崩溃、没有 SquashFS 的“毛坯系统”，把正确的分区和文件一次性物理写入 U 盘。

操作步骤（Mac 终端）

由于之前已经熟悉了 dd 操作，这次直接针对这个新文件进行逻辑闭环操作：

1. 确认文件大小

在 Mac 终端查看该文件大小：

ls -lh ~/Downloads/USG3-4_4_51-Recovery.bin

2. 执行刷写命令

请确保 U 盘已插入，并确认它是 disk2（或者你通过 diskutil list 看到的其他编号）：

很多社员分享的 .bin 镜像是用 OSForensics（一个 Windows 下的取证工具）制作的。这个工具在物理镜像的最前面增加了一个 512 字节（即 1 个扇区）的自定义文件头。

要使用 skip=1 bs=512 参数。这个参数告诉 dd：从源文件的第 513 字节开始读，但从目标 U 盘的第 0 字节开始写。

请严格执行以下命令：

# 1. 确保解除挂载
diskutil unmountDisk /dev/disk2

# 2. 执行带有 skip 参数的物理写入
# 注意：if 是输入文件，of 是 U 盘，skip=1 表示跳过源文件的第一个块（512字节）
sudo dd if="/Users/Carl/Downloads/USG3-4_4_51-Recovery.bin" of=/dev/rdisk2 skip=1 bs=512 status=progress

# 2. 快速写入逻辑：精确跳过 512 字节，但以 1MB 为单位高速写入 U 盘
sudo dd if="/Users/Carl/Downloads/USG3-4_4_51-Recovery.bin" of=/dev/rdisk2 ibs=512 skip=1 obs=1m status=progress

# 3. 强制刷入缓存并弹出
sync
diskutil eject /dev/disk2

刷完插回设备后的“逻辑金标准”验证

请在插好 U 盘并重启 USG 后，再次 SSH 进入（密码是 ubnt），执行你最关心的三项检查：

  1. 挂载点：mount | grep squashfs
  1. DPI 引擎：ls -l /usr/sbin/ubnt-dpi-engine
  1. 系统命令：show system statistics dpi

结果

❯ ssh ubnt@192.168.1.1
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
ED25519 key fingerprint is SHA256:09qpsQxPnzBusFGixcuo3/E9pOFfC3dNFryzRbKpU50.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.1' (ED25519) to the list of known hosts.
Welcome to EdgeOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement (available in the Web UI at, by default,
http://192.168.1.1) and agree to be bound by its terms.

ubnt@192.168.1.1's password: 
Linux ubnt 3.10.107-UBNT #1 SMP Wed Apr 8 20:42:08 UTC 2020 mips64

  ___ ___      .__________.__
 |   |   |____ |__\_  ____/__|
 |   |   /    \|  ||  __) |  |   (c) 2010-2020
 |   |  |   |  \  ||  \   |  |   Ubiquiti, Inc.
 |______|___|  /__||__/   |__|
            |_/                  https://www.ui.com

      Welcome to EdgeOS on UniFi Security Gateway!


 **********************  WARNING!  **********************
 * Configuration changes made here are not persistent.  *
 * They will be overwritten by the controller on next   *
 * provision. Configuration must be done in controller. *
 ********************************************************

ubnt@ubnt:~$ 
ubnt@ubnt:~$ 
ubnt@ubnt:~$ mount | grep squashfs
ubnt@ubnt:~$ ls -l /usr/sbin/ubnt-dpi-engine
ls: /usr/sbin/ubnt-dpi-engine: No such file or directory
ubnt@ubnt:~$ show system statistics dpi
Invalid command
ubnt@ubnt:~$ 

ubnt@ubnt:~$ show version
Version:      v4.4.51
Build ID:     5287926
Build on:     04/08/20 20:34
Copyright:    2012-2020 Ubiquiti, Inc.
HW model:     UniFi-Gateway-3
HW S/N:       b4fbe425a4e7
Uptime:       22:12:04 up 6 min,  3 users,  load average: 0.08, 0.32, 0.20
ubnt@ubnt:~$

换回原装 U 盘不折腾了

经过各种测试，最后发现应该是不行。

可能官方定制的固件就是如此。

等待后续

？？？

AI 结论

USG-3P 其实是有 DPI 引擎的（只是文件名和加载方式跟 UDM 不同）。 社区大量真实 USG-3P 用户贴里都直接用到以下命令（不是虚构）：

这些文件在标准 USG-3P 上是存在的，只是默认不会常驻运行，必须在 UniFi Network 控制器里打开 Traffic & Device Identification 后，控制器才会把签名和配置下发，引擎才启动。 你之前看到 “command not found” 很可能就是因为当时 DPI 还没在控制器里启用，或者 SSH 时引擎还没加载。

其他 AI（包括 ChatGPT、Claude、甚至我早期的一些通用回答）大部分都把 USG-3P 和 UDM/EdgeRouter 的实现混在一起讲了，导致容易出现以下问题：

现在如果想实际验证 DPI 引擎是否存在，可以直接在 SSH 里敲：

ls /usr/sbin/ | grep -E 'dpi|ubnt'

或者先在控制器打开 Traffic Identification 后再看。

装回并控制器接管

更换 U 盘或底层重刷固件后，USG-3P 会恢复到出厂默认状态（192.168.1.1）。要让它无缝接回原有的 192.168.2.x 网段并让控制器重新“认主”，请严格按照以下步骤操作。

第一步：初始化登录与环境清理

由于系统指纹（Host Key）已变，你的 Mac 会因为安全机制拒绝连接。

  1. 清理 SSH 缓存：

    在 Mac 终端运行，防止“身份变更”报警：

ssh-keygen -R 192.168.1.1

  1. 物理连接：

    用网线直连 Mac 和 USG 的 LAN1 口，手动设置 Mac 的 IP 为 192.168.1.10。

  2. 初次登录：

    浏览器访问 https://192.168.1.1（默认账号密码：ubnt / ubnt）。

第二步：配置网段，对齐生产环境

为了能让 USG 顺利接入你原本的 192.168.2.x 网络并找到控制器，必须先修改它的 LAN 口网段。

  1. 将 Mac 的手动 IP 改为 192.168.2.x 网段。
  2. 或者直接将 USG 接入原有的交换机网络。

第三步：控制器端的“断舍离”

这是最容易被忽略的一步： 在重新接管之前，你必须先在 UniFi 控制器中删除这台设备的“前世记忆”。

  1. 打开控制器界面（通常是你的 NAS 或 CloudKey）。
  2. 在 Devices 列表中找到那台显示 Offline 或 Disconnected 的旧 USG。
  3. 进入 Settings -> Manage Device，点击 Forget（删除）。只有彻底删除旧记录，新系统才能顺利发起 Adoption 请求。

第四步：手动引导 Adoption

由于 USG 目前还不知道控制器的具体位置，我们需要手动给它“指路”。

也可以直接打开网页 192.168.2.1 进行设置，更方便。

  1. SSH 登录新 IP：
ssh ubnt@192.168.2.1

  1. 推送 Inform 地址：

    输入以下指令，告知控制器位置（假设控制器 IP 为 192.168.2.20）：

    Bash

set-inform http://192.168.2.20:8080/inform

注意： 协议头是 http 而非 https，端口固定为 8080。

第五步：完成最后的“握手”

  1. 回到控制器页面： 你会看到 USG 状态变为 Pending Adoption。
  2. 点击 Adopt： 稍等片刻，USG 的指示灯会从白色常亮变为蓝色常亮。
  3. 回到 USG 本地管理页： 点击 Confirm 确认 Inform URL 已生效。
使用 Discussions 讨论 在 Github 上编辑 分享到 Twitter