检查 iptables 规则的常用命令：#

查看所有规则#

bash

1
# 查看所有链的规则（最常用）
2
sudo iptables -L
3

4
# 显示详细信息（包含包计数、字节数）
5
sudo iptables -L -v
6

7
# 显示规则序号（方便删除）
8
sudo iptables -L --line-numbers
9

10
# 不解析域名，直接显示 IP（速度更快）
11
sudo iptables -L -n
12

13
# 组合使用（推荐）
14
sudo iptables -L -n -v --line-numbers

查看特定表#

iptables 有四张表：filter（默认）、nat、mangle、raw

bash

1
# 查看 NAT 表
2
sudo iptables -t nat -L -n -v
3

4
# 查看 mangle 表
5
sudo iptables -t mangle -L -n -v
6

7
# 查看 raw 表
8
sudo iptables -t raw -L -n -v

查看特定链#

bash

1
# 只查看 INPUT 链
2
sudo iptables -L INPUT -n -v
3

4
# 只查看 OUTPUT 链
5
sudo iptables -L OUTPUT -n -v
6

7
# 只查看 FORWARD 链
8
sudo iptables -L FORWARD -n -v

以规则格式输出（便于备份/还原）#

bash

1
sudo iptables-save
2

3
# 保存到文件
4
sudo iptables-save > /etc/iptables/rules.v4
5
```
6

7
## 输出示例解读
8
```
9
Chain INPUT (policy ACCEPT)
10
target     prot  opt  source       destination
11
ACCEPT     tcp   --   0.0.0.0/0    0.0.0.0/0    tcp dpt:22
12
DROP       tcp   --   10.0.0.1     0.0.0.0/0

推荐日常使用：

bash

1
sudo iptables -L -n -v --line-numbers

这条命令信息最全，且不会因 DNS 解析导致卡顿。

gx@Ali-ECS:~$ sudo iptables -L [sudo] password for gx: Chain INPUT (policy DROP)括号里是什么意思 target prot opt source destination ACCEPT tcp — anywhere anywhere tcp dpt:9009 ACCEPT tcp — anywhere anywhere tcp dpt:8000 ACCEPT tcp — anywhere anywhere tcp dpt

3月16日

(policy DROP) 的含义#

括号里的 policy（默认策略） 表示：当数据包不匹配链中任何规则时，默认执行的动作。

1
Chain INPUT (policy DROP)

意思是：所有进入的流量，如果没有匹配到上面任何一条 ACCEPT 规则，就会被直接丢弃。

数据包的匹配流程#

1
incoming packet
2
      ↓
3
ACCEPT tcp dpt:9009  ← 匹配到? → 放行
4
      ↓ 否
5
ACCEPT tcp dpt:8000  ← 匹配到? → 放行
6
      ↓ 否
7
ACCEPT tcp dpt:80    ← 匹配到? → 放行
8
      ↓ 否
9
policy DROP          ← 没有任何规则匹配 → 丢弃 ✗

两种默认策略对比#

你当前的配置解读#

你的服务器采用白名单模式，目前只开放了三个端口：

⚠️ 注意：如果你还需要 SSH（端口 22）远程连接，要确认是否有放行规则，否则断开后将无法重连！

policy DROP是如何设置的

3月16日

设置 policy 的命令#

使用 -P 参数设置默认策略：

bash

1
# 设置 INPUT 链默认丢弃
2
sudo iptables -P INPUT DROP
3

4
# 设置为默认放行
5
sudo iptables -P INPUT ACCEPT

⚠️ 操作前的重要警告#

在设置 INPUT DROP 之前，必须先放行 SSH（端口22），否则会立刻断开连接且无法找回！

正确的操作顺序：

bash

1
# 第一步：先放行 SSH
2
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
3

4
# 第二步：放行已建立的连接（非常重要）
5
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
6

7
# 第三步：放行本地回环
8
sudo iptables -A INPUT -i lo -j ACCEPT
9

10
# 第四步：最后再设置默认 DROP
11
sudo iptables -P INPUT DROP

查看当前所有链的 policy#

bash

1
sudo iptables -L | grep policy
2
```
3

4
输出示例：
5
```
6
Chain INPUT (policy DROP)
7
Chain FORWARD (policy ACCEPT)
8
Chain OUTPUT (policy ACCEPT)

规则重启后会丢失#

iptables 规则默认重启后失效，需要持久化保存：

bash

1
# Debian/Ubuntu
2
sudo apt install iptables-persistent
3
sudo netfilter-persistent save
4

5
# CentOS/RHEL
6
sudo service iptables save

完整的iput链如下：为什么我可以ssh的？gx@Ali-ECS:~$ sudo iptables -L [sudo] password for gx: Chain INPUT (policy DROP) target prot opt source destination ACCEPT tcp — anywhere anywhere tcp dpt:9009 ACCEPT tcp — anywhere anywhere tcp dpt:8000 ACCEPT tcp — anywhere anywhere tcp dpt ufw-before-logging-input all — anywhere anywhere ufw-before-input all — anywhere anywhere ufw-after-input all — anywhere anywhere ufw-after-logging-input all — anywhere anywhere ufw-reject-input all — anywhere anywhere ufw-track-input all — anywhere anywhere

3月16日

因为你装了 UFW（Uncomplicated Firewall），SSH 的放行规则在 UFW 的子链里，而不是直接写在 INPUT 链上。

数据包实际流程#

1
incoming packet
2
      ↓
3
ACCEPT dpt:9009   ← 不匹配
4
      ↓
5
ACCEPT dpt:8000   ← 不匹配
6
ACCEPT dpt:80     ← 不匹配
7
      ↓
8
ufw-before-input  ← 跳转进入 UFW 子链 ✓
9
      ↓
10
（在子链里匹配到 SSH 22 端口 → ACCEPT）
11
      ↓
12
SSH 放行成功 ✅

数据包不会直达 policy DROP，因为中途已经被 UFW 子链处理了。

验证：查看 UFW 子链里的 SSH 规则#

bash

1
# 查看 ufw-before-input 子链
2
sudo iptables -L ufw-before-input -n -v
3

4
# 或者直接用 ufw 查看
5
sudo ufw status verbose
6
```
7

8
你会看到类似：
9
```
10
ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0    tcp dpt:22
11
```
12

13
---
14

15
## 你当前环境的结构
16
```
17
iptables INPUT 链
18
├── 手动添加的规则（9009、8000、80）
19
└── UFW 接管的子链
20
    ├── ufw-before-input   ← SSH 22 在这里放行
21
    ├── ufw-after-input
22
    └── ufw-reject-input   ← UFW 的兜底拒绝
23
          ↓
24
       policy DROP          ← 几乎不会走到这里

💡 你的服务器上同时存在手动 iptables 规则和 UFW 规则，建议统一用一种方式管理，混用容易出现规则冲突或难以维护的问题。

gx@Ali-ECS:~$ sudo iptables -L ufw-before-input -n -v Chain ufw-before-input (1 references) pkts bytes target prot opt in out source destination 5123 453K ACCEPT all — lo * 0.0.0.0/0 0.0.0.0/0 429K 240M ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 346 16561 ufw-logging-deny all — * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID 346 16561 DROP all — * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID 0 0 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0 icmptype 3 0 0 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0 icmptype 11 0 0 ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0 icmptype 12 5206 391K ACCEPT icmp — * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 0 0 ACCEPT udp — * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68 5111K 324M ufw-not-local all — * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT udp — * * 0.0.0.0/0 224.0.0.251 udp dpt:5353 0 0 ACCEPT udp — * * 0.0.0.0/0 239.255.255.250 udp dpt:1900 5111K 324M ufw-user-input all — * * 0.0.0.0/0 0.0.0.0/0

Show more

3月16日

找到了！SSH 能连接的原因在第二条规则：

关键规则#

1
429K  240M ACCEPT  all  --  *  *  0.0.0.0/0  0.0.0.0/0  ctstate RELATED,ESTABLISHED

ctstate RELATED,ESTABLISHED 的意思是：已经建立的连接，直接放行，不再检查其他规则。

你的 SSH 会话在第一次连接建立后，后续所有数据包都命中这条规则，所以一直保持畅通。

完整的子链逻辑解读#

那新的 SSH 连接怎么进来的？#

第一次握手走的是最后一条 ufw-user-input 子链，可以再看看：

bash

1
sudo iptables -L ufw-user-input -n -v

SSH 的 ACCEPT dpt:22 规则应该就在那里。一旦握手成功建立连接，后续就全靠 ESTABLISHED 规则放行了。

那为啥我在加这个前ACCEPT tcp — anywhere anywhere tcp dpt，80端口不能访问？

3月16日

很好的问题！因为 80 端口的请求是新连接，不是已建立的连接，所以走不到 ESTABLISHED 那条规则。

新连接 vs 已建立连接#

为什么 SSH 没问题，80 端口却不行？#

因为你 SSH 已经连上了，状态是 ESTABLISHED，直接被放行。

而浏览器访问 80 端口是全新的连接（NEW），需要在规则里找到一条明确的 ACCEPT dpt:80 才能放行。

查看 ufw-user-input 子链#

bash

1
sudo iptables -L ufw-user-input -n -v
2
```
3

4
加规则之前，这个子链里很可能**没有 80 端口**的放行规则，而 UFW 也没有开放 80，所以新连接一路走到底，最终被 `policy DROP` 丢弃：
5
```
6
新连接 dpt:80
7
      ↓
8
ESTABLISHED? ✗（新连接，不是已建立的）
9
      ↓
10
ufw-user-input ✗（没有 80 的规则）
11
      ↓
12
policy DROP ✗ 丢弃
13
```
14

15
加了 `ACCEPT tcp dpt:80` 之后：
16
```
17
新连接 dpt:80
18
      ↓
19
ACCEPT tcp dpt:http ✓ 命中！放行 ✅

这就是为什么加那条规则之后 80 端口才能访问的原因。

“ 80 端口的请求是新连接，不是已建立的连接”是什么意思？我断开SSH后再从新连上去为什么也可以？

3月16日

好问题！这是 TCP 连接状态的概念，跟”你有没有断开过”无关。

关键理解：每次 TCP 握手都是”新连接”#

1
你的电脑                    服务器
2
   |                          |
3
   |--- SYN ----------------> |  ← 这一刻状态是 NEW
4
   |<-- SYN-ACK ------------- |
5
   |--- ACK ----------------> |  ← 握手完成，状态变为 ESTABLISHED
6
   |                          |
7
   |=== 正常通信 ============= |  ← 所有后续包都是 ESTABLISHED

ESTABLISHED 不是指”历史上连接过”，而是指”当前这条连接的后续数据包”。

SSH 重连的实际过程#

你断开 SSH 再重连，发生了两件事：

第一次握手（NEW）：

1
SYN 包 → ctstate NEW
2
       → 走到 ufw-user-input
3
       → 命中 ACCEPT dpt:22
4
       → 放行 ✅

握手成功后的后续包（ESTABLISHED）：

1
后续数据包 → ctstate ESTABLISHED
2
           → 第二条规则直接放行 ✅

所以每次重连都能成功，是因为 SSH 22 端口在 ufw-user-input 里有放行规则，新连接握手能通过。

对比 80 端口（加规则前）#

1
浏览器 SYN 包 → ctstate NEW
2
              → ufw-user-input 里没有 dpt:80
3
              → policy DROP ✗

80 端口的握手第一步就被拦截了，永远到不了 ESTABLISHED 状态，所以怎么试都不通。

一句话总结#

ESTABLISHED 是实时跟踪当前连接的状态，不是记忆历史。每次新连接都必须先过 NEW 这一关，SSH 有规则放行，80 端口没有所以不通。

gx@Ali-ECS:~$ sudo iptables -L [sudo] password for gx: Chain INPUT (policy DROP) target prot opt source destination ACCEPT tcp — anywhere anywhere tcp dpt:9009 ACCEPT tcp — anywhere anywhere tcp dpt:8000 ACCEPT tcp — anywhere anywhere tcp dpt ufw-before-logging-input all — anywhere anywhere ufw-before-input all — anywhere anywhere ufw-after-input all — anywhere anywhere ufw-after-logging-input all — anywhere anywhere ufw-reject-input all — anywhere anywhere ufw-track-input all — anywhere anywhere 后面这几个以ufw-开头的rule是什么意思

Show more

3月16日

UFW 子链的作用#

这几条规则是 UFW 自动插入的跳转规则，把数据包依次送入不同职责的子链处理。就像一条流水线：

1
数据包进入 INPUT
2
      ↓
3
ufw-before-logging-input   第1站：连接前记录日志
4
      ↓
5
ufw-before-input           第2站：UFW 核心处理（放行合法流量）
6
      ↓
7
ufw-after-input            第3站：处理后的收尾工作
8
      ↓
9
ufw-after-logging-input    第4站：连接后记录日志
10
      ↓
11
ufw-reject-input           第5站：明确拒绝的流量（返回REJECT）
12
      ↓
13
ufw-track-input            第6站：连接跟踪统计

每条子链的职责#

为什么要拆成这么多子链？#

UFW 这样设计是为了职责分离，方便管理：

1
你执行 sudo ufw allow 22
2
  → UFW 只修改 ufw-user-input 子链
3
  → 不影响其他子链
4
  → 规则互不干扰

如果全堆在 INPUT 链里，规则一多就很难维护。

注意你当前的混用问题#

你的 INPUT 链顶部有手动添加的规则：

1
ACCEPT tcp dpt:9009   ← 手动添加
2
ACCEPT tcp dpt:8000   ← 手动添加
3
ACCEPT tcp dpt:http   ← 手动添加
4
── UFW 子链 ──────────── UFW 管理

这两套规则互不知道对方的存在，建议统一用 UFW 管理：

bash

1
sudo ufw allow 9009
2
sudo ufw allow 8000
3
sudo ufw allow 80
4
# 然后删除手动添加的规则
5
sudo iptables -D INPUT -p tcp --dport 9009 -j ACCEPT

记录最终被拒绝的包的日志，这个怎么查看？

3月16日

查看被拒绝的包的日志#

UFW 的日志记录在系统日志里：

bash

1
# 最常用：直接查看 UFW 日志
2
sudo grep "UFW BLOCK" /var/log/ufw.log
3

4
# 实时监控（看有没有新的被拦截的包）
5
sudo tail -f /var/log/ufw.log
6

7
# 如果 ufw.log 不存在，从 syslog 里找
8
sudo grep "UFW BLOCK" /var/log/syslog
9
```
10

11
---
12

13
## 日志格式解读
14

15
一条典型的日志长这样：
16
```
17
Mar 16 10:23:11 Ali-ECS kernel: [UFW BLOCK] IN=eth0 OUT= MAC=... SRC=1.2.3.4 DST=你的IP LEN=44 ... PROTO=TCP SPT=54321 DPT=3306 ...

按端口筛选#

bash

1
# 查看有人扫哪些端口
2
sudo grep "UFW BLOCK" /var/log/ufw.log | grep "DPT=22"
3

4
# 统计被拦截次数最多的来源 IP
5
sudo grep "UFW BLOCK" /var/log/ufw.log | grep -oP 'SRC=\S+' | sort | uniq -c | sort -rn | head 10
6

7
# 统计被探测最多的端口
8
sudo grep "UFW BLOCK" /var/log/ufw.log | grep -oP 'DPT=\S+' | sort | uniq -c | sort -rn | head 10

如果没有日志，先开启 UFW 日志#

bash

1
# 查看当前日志级别
2
sudo ufw status verbose | grep Logging
3

4
# 开启日志
5
sudo ufw logging on
6

7
# 日志级别（low/medium/high）
8
sudo ufw logging medium

Mar 16 11:54:27 Ali-ECS kernel: [252100.423682] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:01:49:10:ee:ff:ff:ff:ff:ff:08:00 SRC=198.235.24.94 DST=172.31.28.241 LEN=44 TOS=0x14 PREC=0x00 TTL=238 ID=54321 PROTO=TCP SPT=54810 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 这条日志如何解读

3月16日

逐字段解读#

综合判断#

1
198.235.24.94 正在用扫描工具探测你的 80 端口

几个明显的扫描特征同时出现：

• ID=54321 — 整数，扫描工具惯用伪造值
• WINDOW=65535 — 最大窗口，扫描工具默认值
• LEN=44 — 纯 SYN 包，只探测端口是否开放
• TTL=238 — 非正常操作系统默认值

UFW 已经正确拦截了这个包，你的服务器是安全的。 ✅

可以查一下这个 IP#

bash

1
# 查询 IP 归属
2
whois 198.235.24.94
3

4
# 或者直接在线查
5
curl ipinfo.io/198.235.24.94

gx@Ali-ECS:~ curl ipinfo.io/198.235.24.94 { "ip": "198.235.24.94", "city": "Chang-hua", "region": "Taiwan", "country": "TW", "loc": "24.0733,120.5628", "org": "AS396982 Google LLC", "timezone": "Asia/Taipei", "readme": "<https://ipinfo.io/missingauth>" }gx@Ali-ECS:\~

3月16日

解读结果#

关键点：这是 Google 的 IP#

这个 IP 属于 Google Cloud（GCP） 的云服务器，不是普通用户。

可能的情况：

1. 有人租用 GCP 服务器在跑扫描工具（最可能）

1
黑客/研究者 → 租一台 GCP 云主机 → 跑端口扫描 → 扫到你的 80 端口

2. 安全研究机构的扫描

• 互联网上有很多安全公司（Shodan、Censys 等）会定期扫描全网开放端口，建立互联网资产数据库

3. Google 自己的爬虫/探测

• 可能性较低，Google 爬虫一般走 443/80 且有明确的 User-Agent

要不要屏蔽它？#

不必专门屏蔽，因为：

• UFW 已经拦截了 ✅
• 互联网上这类扫描每天都有很多，是正常现象
• 屏蔽一个 IP 意义不大，换个 IP 继续扫

bash

1
# 看看你每天被扫了多少次
2
sudo grep "UFW BLOCK" /var/log/ufw.log | wc -l
3

4
# 看看都有哪些 IP 在扫你
5
sudo grep "UFW BLOCK" /var/log/ufw.log | grep -oP 'SRC=\S+' | sort | uniq -c | sort -rn | head 10

💡 只要不该开放的端口都关着，这些扫描对你毫无威胁，UFW 默默挡住就好了。

看一下这条呢 Mar 16 11:44:31 Ali-ECS kernel: [251504.249512] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:01:49:10:ee:ff:ff:ff:ff:ff:08:00 SRC=39.100.103.42 DST=172.31.28.241 LEN=60 TOS=0x14 PREC=0x00 TTL=53 ID=51080 DF PROTO=TCP SPT=49652 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0

3月16日

对比解读#

先查一下这个 IP#

bash

1
curl ipinfo.io/39.100.103.42

初步判断#

这条和上一条明显不同，特征更像一个真实用户在访问你的 80 端口：

• LEN=60 — 正常 TCP SYN 包大小（Linux 默认就是60）
• TTL=53 — 正常，说明经过了约 11 跳路由（64-53=11）
• ID=51080 — 随机值，非伪造
• WINDOW=29200 — Linux 内核默认初始窗口大小
• DF — 正常 Linux 系统都会设置

💡 结论：这更像是一个真实的人/服务器在尝试访问你的 80 端口，而不是扫描工具。先查一下 IP 归属再判断是谁。

ufw和iptables什么关系

3月16日

UFW 和 iptables 的关系#

UFW 是 iptables 的前端管理工具，底层还是 iptables 在干活。

1
你执行命令
2
    ↓
3
sudo ufw allow 22
4
    ↓
5
UFW 翻译成 iptables 规则
6
    ↓
7
sudo iptables -A ufw-user-input -p tcp --dport 22 -j ACCEPT
8
    ↓
9
Linux 内核 netfilter 执行

类比理解#

1
iptables  ←→  汽车发动机（功能强大，但操作复杂）
2
UFW       ←→  方向盘+油门（简单易用的操作界面）

对比#

你的服务器现状#

1
Linux 内核 netfilter
2
        ↑
3
    iptables 规则
4
    ┌───────────────────────────┐
5
    │ 手动添加的规则             │  ← 你直接用 iptables 加的
6
    │ ACCEPT dpt:9009           │
7
    │ ACCEPT dpt:8000           │
8
    │ ACCEPT dpt:80             │
9
    ├───────────────────────────┤
10
    │ UFW 管理的规则             │  ← UFW 自动生成的
11
    │ ufw-before-input          │
12
    │ ufw-user-input (SSH 22)   │
13
    │ ufw-after-input           │
14
    └───────────────────────────┘

两套规则同时生效，所以建议统一用 UFW 管理，避免混乱：

bash

1
# 用 UFW 替代手动的 iptables 规则
2
sudo ufw allow 80
3
sudo ufw allow 8000
4
sudo ufw allow 9009
5

6
# 删除手动添加的 iptables 规则
7
sudo iptables -D INPUT -p tcp --dport 80 -j ACCEPT
8
sudo iptables -D INPUT -p tcp --dport 8000 -j ACCEPT
9
sudo iptables -D INPUT -p tcp --dport 9009 -j ACCEPT

ufw是什么

3月16日

UFW 是什么#

UFW = Uncomplicated Firewall，直译就是”不复杂的防火墙”，是 Ubuntu/Debian 系统上默认的防火墙管理工具，由 Ubuntu 团队开发。

它解决了什么问题#

iptables 虽然强大，但命令太繁琐：

bash

1
# iptables 开放一个端口要写这么长
2
sudo iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
3
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
4
sudo iptables-save > /etc/iptables/rules.v4  # 还要手动持久化
5

6
# UFW 只需要一行
7
sudo ufw allow 22

常用命令#

bash

1
# 开启/关闭防火墙
2
sudo ufw enable
3
sudo ufw disable
4

5
# 查看状态
6
sudo ufw status verbose
7

8
# 开放端口
9
sudo ufw allow 22        # 开放 SSH
10
sudo ufw allow 80        # 开放 HTTP
11
sudo ufw allow 443       # 开放 HTTPS
12

13
# 只允许特定 IP 访问
14
sudo ufw allow from 192.168.1.1 to any port 22
15

16
# 删除规则
17
sudo ufw delete allow 80
18

19
# 查看规则编号
20
sudo ufw status numbered
21
# 按编号删除
22
sudo ufw delete 3
23
```
24

25
---
26

27
## UFW 在 Ubuntu 上的地位
28
```
29
Ubuntu 系统
30
└── 内置 iptables（底层）
31
└── 内置 UFW（管理工具）
32
    └── 你安装的应用（如 Docker、Nginx）
33
        会自动往 UFW/iptables 里加规则

💡 Ubuntu 上推荐用 UFW 管理防火墙。CentOS/RHEL 系统上对应的工具是 firewalld，底层同样是 iptables。

ubuntu系统，如何连wifi

3月17日

Ubuntu 连 WiFi 有几种方式，取决于你用的是桌面版还是服务器版：

Q: 你的 Ubuntu 是哪种环境？ A: 服务器版（纯命令行）

3月17日

服务器版 Ubuntu 连 WiFi#

服务器版用 nmcli（NetworkManager 命令行工具）来管理网络。

第一步：确认 WiFi 网卡存在#

bash

1
# 查看网络设备
2
nmcli device status
3
```
4

5
输出示例：
6
```
7
DEVICE   TYPE      STATE      CONNECTION
8
eth0     ethernet  connected  有线连接
9
wlan0    wifi      disconnected  --       ← WiFi 网卡

第二步：扫描附近 WiFi#

bash

1
nmcli device wifi list
2
```
3

4
输出示例：
5
```
6
SSID            MODE   CHAN  RATE    SIGNAL  SECURITY
7
MyWiFi          Infra  6     54 Mbit  85      WPA2
8
neighbor_wifi   Infra  11    54 Mbit  60      WPA2

第三步：连接 WiFi#

bash

1
# 连接 WPA2 加密的 WiFi（最常见）
2
sudo nmcli device wifi connect "WiFi名称" password "WiFi密码"
3

4
# 例如
5
sudo nmcli device wifi connect "MyWiFi" password "12345678"

其他常用命令#

bash

1
# 查看当前连接状态
2
nmcli connection show
3

4
# 断开 WiFi
5
nmcli device disconnect wlan0
6

7
# 重新连接上次的 WiFi
8
nmcli connection up "WiFi名称"
9

10
# 删除已保存的 WiFi
11
nmcli connection delete "WiFi名称"

如果 nmcli 不可用#

bash

1
# 检查 NetworkManager 是否运行
2
systemctl status NetworkManager
3

4
# 没运行就启动
5
sudo systemctl start NetworkManager
6
sudo systemctl enable NetworkManager  # 开机自启

💡 注意：阿里云 ECS 服务器是云主机，没有物理网卡，无法连 WiFi。如果你是在本地的 Ubuntu 服务器或虚拟机上操作，以上命令才适用。

PS D:\repo\blog_demo_with_astro\super-sphere> npm run dev > super-sphere@0.0.1 dev > astro dev ‘astro’ 不是内部或外部命令，也不是可运行的程序 或批处理文件。

3月17日

这是 npm 依赖没有正确安装或路径问题。

解决方法#

第一步：重新安装依赖

bash

1
npm install

第二步：再次运行

bash

1
npm run dev

如果还不行，可能的原因和解决方式#

原因1：node_modules 损坏

bash

1
# 删除 node_modules 和 lock 文件，重新安装
2
rm -rf node_modules
3
rm package-lock.json
4
npm install

原因2：npm 没有把本地 bin 加入路径

bash

1
# 用 npx 直接运行
2
npx astro dev

原因3：node 版本太低（Astro 需要 Node.js 18+）

bash

1
# 查看当前版本
2
node -v
3

4
# 如果版本低，去 https://nodejs.org 下载最新 LTS 版本
5
```
6

7
---
8

9
## 推荐排查顺序
10
```
11
npm install
12
    ↓ 还不行
13
npx astro dev
14
    ↓ 还不行
15
node -v 检查版本
16
    ↓ 还不行
17
删除 node_modules 重装

通常 npm install 之后就能解决。

如何添加这几条规则到INPUT chain：ACCEPT tcp — anywhere anywhere tcp dpt:9009 ACCEPT tcp — anywhere anywhere tcp dpt:8000 ACCEPT tcp — anywhere anywhere tcp dpt

16:15

对应的 iptables 命令如下：

bash

1
sudo iptables -A INPUT -p tcp --dport 9009 -j ACCEPT
2
sudo iptables -A INPUT -p tcp --dport 8000 -j ACCEPT
3
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

参数解释#

⚠️ 注意插入位置#

-A 是追加到末尾，但你现在的 INPUT 链顶部已经有 UFW 的子链规则。如果想插入到最顶部（在 UFW 规则之前生效），用 -I 代替 -A：

bash

1
# -I 插入到第1行
2
sudo iptables -I INPUT 1 -p tcp --dport 9009 -j ACCEPT
3
sudo iptables -I INPUT 2 -p tcp --dport 8000 -j ACCEPT
4
sudo iptables -I INPUT 3 -p tcp --dport 80 -j ACCEPT

验证是否添加成功#

bash

1
sudo iptables -L INPUT -n -v --line-numbers

重启后规则会丢失，记得持久化#

bash

1
# Ubuntu/Debian
2
sudo apt install iptables-persistent
3
sudo netfilter-persistent save

不安装那个程序能让规则持久化吗？

16:22

可以，手动保存和加载规则即可。

方法：用脚本开机自动加载#

第一步：保存当前规则到文件

bash

1
sudo iptables-save > /etc/iptables.rules

第二步：创建开机自启脚本

bash

1
sudo nano /etc/rc.local

写入以下内容：

bash

1
#!/bin/bash
2
iptables-restore < /etc/iptables.rules
3
exit 0

第三步：赋予执行权限

bash

1
sudo chmod +x /etc/rc.local

更推荐的方式：systemd service#

rc.local 在新版 Ubuntu 上不一定可靠，更稳妥的方式是创建一个 systemd 服务：

第一步：保存规则

bash

1
sudo iptables-save > /etc/iptables.rules

第二步：创建服务文件

bash

1
sudo nano /etc/systemd/system/iptables-restore.service

写入：

ini

1
[Unit]
2
Description=Restore iptables rules
3
Before=network.target
4

5
[Service]
6
Type=oneshot
7
ExecStart=/sbin/iptables-restore /etc/iptables.rules
8
RemainAfterExit=yes
9

10
[Install]
11
WantedBy=multi-user.target

第三步：启用服务

bash

1
sudo systemctl daemon-reload
2
sudo systemctl enable iptables-restore.service

以后每次修改规则后，记得重新保存#

bash

1
sudo iptables-save > /etc/iptables.rules

💡 这两种方法本质一样，都是开机时执行 iptables-restore 重新加载规则。systemd 方式更可靠，推荐用第二种。

我还是安装iptables-persistent吧，是不是每次修改了规则，都要运行sudo netfilter-persistent save来持久化？

16:24

是的，每次修改规则后都需要手动运行一次保存命令：

bash

1
sudo netfilter-persistent save
2
```
3

4
---
5

6
## 它做了什么
7
```
8
sudo netfilter-persistent save
9
        ↓
10
把当前 iptables 规则保存到文件
11
        ↓
12
/etc/iptables/rules.v4   ← IPv4 规则
13
/etc/iptables/rules.v6   ← IPv6 规则
14
        ↓
15
开机时自动从这两个文件恢复规则

容易踩的坑#

改了规则，忘记 save，然后重启了 → 规则丢失，一切回到上次 save 的状态

所以养成习惯：

bash

1
# 改完规则，立刻保存
2
sudo iptables -A INPUT -p tcp --dport 9009 -j ACCEPT
3
sudo netfilter-persistent save   ← 改完马上存

验证规则是否已保存#

bash

1
cat /etc/iptables/rules.v4

能看到你的规则说明保存成功了。