排错 on Liangweidong's blog

MySQL 用户权限与安全实战：账号、密码、远程连接与排错

Fri, 15 Jun 2018 00:00:00 +0800

为什么写这篇：MySQL 日常 80% 的运维问题都跟"用户/密码/远程连接"有关——ERROR 1130 远程拒绝、root 密码忘了、caching_sha2_password 客户端不兼容、InnoDB 起不来。本文把所有这些场景整理成可复用的 SOP。

适用读者：需要做 MySQL 账号管理、权限分配、生产排错的 DBA / 运维 / 后端。

前置知识：会用 mysql 客户端、了解 user/host 二元组的概念。

1. 账号体系：`user@host` 二元组

MySQL 的账号由 用户名 + 主机 共同决定——root@localhost 和 root@% 是两个独立的账号，密码可以不同。

host 值	含义
`localhost`	仅本地 socket 连接（不走 TCP）
`127.0.0.1`	本地 TCP（不推荐，与 localhost 不同）
`10.0.0.1`	单 IP
`10.0.0.%`	10.0.0 网段
`10.0.0.0/255.255.255.0`	等价于 `10.0.0.%`（MySQL 不支持 CIDR）
`%`	任意 IP（最不安全）
`host1, host2`	多 IP 用逗号分隔

最佳实践：永远不要用 root@%。生产库至少分 3 个账号：

app_readonly@10.0.0.%：业务读账号，只 SELECT

app_rw@10.0.0.%：业务读写账号，限定特定库

dba@10.0.0.%：DBA 管理账号，运维专用

2. 创建用户与授权：GRANT / REVOKE

2.1 创建用户

1
2
3
4
5


-- 标准语法
CREATE USER 'username'@'host' IDENTIFIED BY 'password';

-- 示例
CREATE USER 'app_user'@'%' IDENTIFIED BY '{{REDACTED}}';

MySQL 5.7+ 默认密码策略是 MEDIUM：8 位以上、大小写 + 数字 + 符号。

2.2 授权（GRANT）

1
2


-- 语法：grant 权限 on 库.表 to 'user'@'host'
GRANT ALL PRIVILEGES ON *.* TO 'app_user'@'%' WITH GRANT OPTION;

权限粒度从大到小：

粒度	语法	适用
全局	`.`	DBA / 超级账号
库级	`industry_iot.*`	业务库应用
表级	`industry_iot.risk_task`	极小权限
列级	`(col1, col2)`	极少用（要 INSERT/SELECT 配合）

完整权限列表（按常用度排序）：

1
2
3
4
5


ALL SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD,
SHUTDOWN, PROCESS, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES,
SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE,
REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE,
CREATE USER, EVENT, TRIGGER, CREATE TABLESPACE, CREATE ROLE, DROP ROLE

MySQL 8.0 还多了 动态权限（dynamic privileges）：

1
2
3
4
5
6
7
8


APPLICATION_PASSWORD_ADMIN, AUDIT_ADMIN, BACKUP_ADMIN, BINLOG_ADMIN,
BINLOG_ENCRYPTION_ADMIN, CLONE_ADMIN, CONNECTION_ADMIN, ENCRYPTION_KEY_ADMIN,
FLUSH_OPTIMIZER_COSTS, FLUSH_STATUS, FLUSH_TABLES, FLUSH_USER_RESOURCES,
GROUP_REPLICATION_ADMIN, INNODB_REDO_LOG_ARCHIVE, INNODB_REDO_LOG_ENABLE,
PERSIST_RO_VARIABLES_ADMIN, REPLICATION_APPLIER, REPLICATION_SLAVE_ADMIN,
RESOURCE_GROUP_ADMIN, RESOURCE_GROUP_USER, ROLE_ADMIN, SERVICE_CONNECTION_ADMIN,
SESSION_VARIABLES_ADMIN, SET_USER_ID, SHOW_ROUTINE, SYSTEM_USER,
SYSTEM_VARIABLES_ADMIN, TABLE_ENCRYPTION_ADMIN, XA_RECOVER_ADMIN

2.3 只授 CRUD（推荐生产）

1
2
3
4


-- 业务账号：只允许 CRUD 业务库
GRANT SELECT, INSERT, UPDATE, DELETE
ON industry_iot_dev.*
TO 'app_user'@'10.0.0.%';

2.4 撤销权限

1
2
3
4
5


-- 撤销所有权限 + 授权选项
REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'app_user'@'%';

-- 撤销特定权限
REVOKE INSERT, UPDATE ON industry_iot_dev.* FROM 'app_user'@'10.0.0.%';

2.5 完整流程：创建 + 授权 + 刷新

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


-- 1. 创建用户
CREATE USER 'app_user'@'%' IDENTIFIED BY '{{REDACTED}}';

-- 2. 授权
GRANT SELECT, INSERT, UPDATE, DELETE
ON industry_iot_dev.*
TO 'app_user'@'%';

-- 3. 刷新（必须有）
FLUSH PRIVILEGES;

-- 4. 验证：用新账号登录
-- mysql -h db_host -u app_user -p'{{REDACTED}}' industry_iot_dev

2.6 一次性创建 + 授权（with grant option）

1

GRANT ALL PRIVILEGES ON industry_iot_dev.* TO 'dev'@'%' IDENTIFIED BY '{{REDACTED}}' WITH GRANT OPTION;

MySQL 8.0 已经不支持 GRANT ... IDENTIFIED BY 这种语法——必须先 CREATE USER 再 GRANT。这种"老语法"在 5.7 升级 8.0 时要全部改一遍。

3. 远程连接排错：ERROR 1130

1

ERROR 1130 (HY000): Host 'xxx' is not allowed to connect to this MySQL server

原因：mysql.user 表里没有匹配 client_ip 的账号。

修法（生产推荐）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 1. 用 mysql_native_password 创建远程专用账号
CREATE USER IF NOT EXISTS 'app_user'@'10.0.0.%'
IDENTIFIED WITH mysql_native_password BY '{{REDACTED}}';

-- 2. 授权（限定库，不给全局）
GRANT SELECT, INSERT, UPDATE, DELETE
ON industry_iot_dev.*
TO 'app_user'@'10.0.0.%';

-- 3. 刷新
FLUSH PRIVILEGES;

临时应急（仅测试用）：

1
2
3
4
5


-- 把 root 改成允许任意 IP
CREATE USER IF NOT EXISTS 'root'@'%'
IDENTIFIED WITH mysql_native_password BY '{{REDACTED}}';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

3.1 Navicat 客户端报错

Authentication plugin 'caching_sha2_password' cannot be loaded

→ 改用 mysql_native_password（见下文 §5）。

3.2 客户端连接慢（5+ 秒才连上）

useDNS=no 没设导致反向 DNS 查询慢。在 my.cnf 加：

1
2


[mysqld]
skip-name-resolve

或对 MySQL 5.7+：

1
2
3


[mysqld]
# 关闭反向 DNS 解析
skip-name-resolve

4. root 密码管理：重置 / 找回

4.1 在线改密码（MySQL 5.7+）

1
2
3
4
5
6
7
8


-- 新版本（推荐）
ALTER USER 'root'@'localhost' IDENTIFIED BY '{{REDACTED}}';

-- 远程访问账号
ALTER USER 'root'@'%' IDENTIFIED BY '{{REDACTED}}';

-- 刷新
FLUSH PRIVILEGES;

4.2 旧版本兼容

1
2
3
4
5
6
7
8
9


-- 5.6 / 5.7 老语法
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('{{REDACTED}}');

-- mysql_native_password 兼容
UPDATE user SET authentication_string = SHA1('{{REDACTED}}') WHERE user = 'root';

-- 允许任意 IP
UPDATE user SET host = '%' WHERE user = 'root';
FLUSH PRIVILEGES;

4.3 忘了密码（找回 SOP）

前提：能物理访问服务器 + 有 my.cnf 编辑权限。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


# 1. 停 MySQL
systemctl stop mysqld

# 2. 临时加 skip-grant-tables
vim /etc/my.cnf
# [mysqld]
# skip-grant-tables

# 3. 启动
systemctl start mysqld

# 4. 空密码登录
mysql -uroot

# 5. 清空 root 密码
USE mysql;
FLUSH PRIVILEGES;
UPDATE user SET authentication_string = '' WHERE user = 'root';

# 6. 退出，注释掉 skip-grant-tables
# 7. 重启
systemctl restart mysqld

# 8. 重新登录（空密码）
mysql -uroot

-- 9. 设置新密码
ALTER USER 'root'@'localhost' IDENTIFIED BY '{{REDACTED}}';
ALTER USER 'root'@'%' IDENTIFIED BY '{{REDACTED}}';
FLUSH PRIVILEGES;

4.4 mysqladmin 一行命令

1
2


# 知道旧密码时最快
mysqladmin -uroot -p'{{OLD_PASSWORD}}' password '{{NEW_PASSWORD}}'

5. mysql_native_password vs caching_sha2_password

维度	`mysql_native_password`	`caching_sha2_password`
引入版本	MySQL 5.6 之前	MySQL 8.0（默认）
算法	SHA1	SHA-256 + cache
性能	较好	更快（首次验证后缓存）
安全性	中（SHA1 已不推荐）	高（不传明文密码）
客户端兼容	全平台	8.0+ Connector、5.7.23+ xdevapi

5.1 老客户端不兼容

老版本 Navicat (11/12)、JDBC 5.x、某些 ORM 框架连接时报：

1

Authentication plugin 'caching_sha2_password' cannot be loaded

修法：

1
2
3
4
5
6


-- 单个账号降级
ALTER USER 'app_user'@'10.0.0.%' IDENTIFIED WITH mysql_native_password BY '{{REDACTED}}';
FLUSH PRIVILEGES;

-- 全局默认改成 mysql_native_password
SET GLOBAL default_authentication_plugin = 'mysql_native_password';

新部署的项目应该用 caching_sha2_password——mysql_native_password 是历史包袱。

5.2 全局修改默认认证插件

1
2
3


# /etc/my.cnf
[mysqld]
default_authentication_plugin = caching_sha2_password

改了之后已存在的用户不受影响，要批量改可以导出现有用户再 SET GLOBAL 重设。

6. InnoDB 启动崩溃：6 级 force_recovery

现象：

1
2
3
4


[InnoDB] Unable to lock ./undo_001 error: 11
2025-01-03T02:52:18 [ERROR] [MY-012562] [InnoDB] We scanned the log up to ...
InnoDB: Assertion failure: log0log.cc:657:first_rec_group <= start_lsn - block_lsn
InnoDB: We intentionally generate a memory trap.

6.1 紧急修法

1
2
3


# 1. 把有问题的 undo 文件备份
mv undo_001 undo_001.bak
cp -a undo_001.bak undo_001

6.2 force_recovery 6 级

1
2
3


# /etc/my.cnf
[mysqld]
innodb_force_recovery = 6

值	含义	影响
1 (SRV_FORCE_IGNORE_CORRUPT)	忽略 corrupt 页	可能丢数据
2 (SRV_FORCE_NO_BACKGROUND)	阻止主线程 full purge	crash 风险
3 (SRV_FORCE_NO_TRX_UNDO)	不执行事务回滚	丢未提交事务
4 (SRV_FORCE_NO_IBUF_MERGE)	不执行插入缓冲合并	性能降
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)	不看重做日志	丢未提交事务
6 (SRV_FORCE_NO_LOG_REDO)	不执行前滚	最后手段

使用原则：从 1 开始逐级试，能起来就用。6 起来后第一件事 mysqldump 全量导出——之后用正常模式重建库。

7. 字符集与排序规则最佳实践

7.1 建库时统一 utf8mb4

1
2
3


CREATE DATABASE industry_iot_dev
DEFAULT CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

7.2 建表时显式声明

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


CREATE TABLE risk_task (
 id INT PRIMARY KEY AUTO_INCREMENT,
 name VARCHAR(64)
 CHARACTER SET utf8mb4
 COLLATE utf8mb4_general_ci
 NOT NULL DEFAULT '',
 -- ...
) ENGINE = InnoDB
 DEFAULT CHARSET = utf8mb4
 COLLATE = utf8mb4_unicode_ci;

7.3 utf8 vs utf8mb4

字符集	最大字符长度	实际能存
`utf8` (MySQL 早期别名)	3 字节	不支持 emoji、部分生僻字
`utf8mb4` (MySQL 5.5.3+)	4 字节	支持 emoji、所有 Unicode

铁律：MySQL 的 utf8 不是真 utf8。新库必须用 utf8mb4。

7.4 排序规则

Collation	特点
`utf8mb4_general_ci`	速度快，不严格按 Unicode 排序
`utf8mb4_unicode_ci`	按 Unicode 标准排序，推荐
`utf8mb4_bin`	按二进制比较（区分大小写）
`utf8mb4_0900_ai_ci`	MySQL 8.0 新 UCA 9.0 算法（默认）

建议：通用场景用 utf8mb4_unicode_ci（8.0 之前）或 utf8mb4_0900_ai_ci（8.0+）。

经验总结

主题	关键 SOP
新用户	`CREATE USER` + `GRANT` + `FLUSH PRIVILEGES`
远程连接	不用 `root@%`；建 `app_user@10.0.0.%` 限定网段
密码忘了	`skip-grant-tables` + 清空密码 + 重设
caching_sha2 兼容	改用 `mysql_native_password`
InnoDB 崩了	`innodb_force_recovery=1~6` 逐级试，6 起来立刻全量导出
字符集	永远 `utf8mb4_unicode_ci`

下一步

MySQL 索引优化：见《MySQL 索引优化实战》
EXPLAIN + SQL 题解：见《MySQL 实战速查》
实时同步 Canal/Debezium：见《MySQL 实时同步实战》

Nginx stream 四层 TCP 代理实战：MSTSC 远程桌面透传与排错

Sun, 15 Sep 2013 00:00:00 +0800

背景

Nginx 早期是 HTTP（七层）反代神器，但从 1.9.0（2015 年）开始，ngx_stream_core_module 提供了四层（TCP/UDP）代理——能代理任何 TCP 协议：

RDP（Windows 远程桌面 3389）
MySQL、Redis、MongoDB
SSH
SMTP、POP3
游戏服务器
自定义 TCP 协议

与 HAProxy/LVS 对比：

维度	Nginx stream	HAProxy	LVS
学习成本	最低	中	高
性能	中等	强	最强
七层能力	同时支持	同时支持	不支持
适用规模	中小（< 5w QPS）	大	超大

典型场景：公司有几台 Windows 服务器，通过一台 Linux 反代把不同端口的 RDP 流量透明转发到不同后端，外网只暴露一个 VIP。

一、Nginx stream 模块基础

1.1 编译参数

stream 模块不是默认编译的，需要 --with-stream：

1
2
3


nginx -V
# 看是否有 --with-stream
# 如果没有，要重编译

重编译步骤：

1
2
3
4
5
6
7


# 看现有参数
nginx -V
# 在最后加 --with-stream
./configure <原参数> --with-stream
make
# 不要 make install（会覆盖），手动替换二进制
cp objs/nginx /usr/local/nginx/sbin/nginx

1.2 配置结构

/etc/nginx/nginx.conf：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 顶层 stream 块（与 http 同级）
stream {
 log_format proxy '$remote_addr [$time_local] '
 '$protocol $status $bytes_sent $bytes_received '
 '$session_time "$upstream_addr" '
 '$upstream_bytes_sent $upstream_bytes_received '
 '$upstream_connect_time';
 
 # 引入 conf.d/ 下的所有 stream 配置
 include /etc/nginx/stream/*.conf;
}

/etc/nginx/stream/rdp.conf：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


upstream rdp_pool {
 hash $remote_addr consistent; # 同一客户端固定连同一后端
 server 10.0.0.10:3389 max_fails=3 fail_timeout=30s;
 server 10.0.0.11:3389 max_fails=3 fail_timeout=30s;
}

server {
 listen 3390; # 外网端口
 proxy_pass rdp_pool; # 转发到 upstream
 proxy_connect_timeout 10s;
 proxy_timeout 300s;
 
 # 自定义日志
 access_log /var/log/nginx/rdp_access.log proxy;
 error_log /var/log/nginx/rdp_error.log;
}

关键点：

stream 块在顶层（与 http 同级），不在 http 里面
监听端口不能与 http 块冲突
没有 server_name、没有 location（四层只看 IP:Port）

二、MSTSC 远程桌面透传实战

场景：公网 IP 47.104.152.64，Windows 内网 RDP 真实地址 10.0.0.10:3389。

2.1 完整配置

1
2
3
4
5
6
7
8
9


stream {
 log_format proxy '[$time_local] $protocol status:$status, '
 'bytes client:$bytes_sent/$bytes_received $session_time, '
 'client: $remote_addr, upstream:"$upstream_addr", '
 'bytes upstream:$upstream_bytes_sent $upstream_bytes_received '
 '$upstream_connect_time';
 
 include /etc/nginx/stream/*.conf;
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# /etc/nginx/stream/rdp.conf
upstream mstsc {
 hash $remote_addr consistent;
 server 10.0.33.101:3389 max_fails=3 fail_timeout=30s;
}

server {
 error_log /var/log/nginx/101_3399_error.log;
 access_log /var/log/nginx/101_3399_access.log proxy;
 listen 3399; # 外网访问 3399
 proxy_connect_timeout 10s;
 proxy_timeout 300s;
 proxy_pass mstsc;
}

客户端连接：mstsc /v:47.104.152.64:3399

2.2 日志样例

1
2
3


[25/Apr/2017:17:55:57 +0800] TCP status:200, bytes client:103/122 10.671, 
client: 192.168.3.218, upstream: "192.168.1.176:59001" 
bytes upstream:122/103 0.000

字段解读：

bytes client:103/122：客户端发送 103 字节，接收 122 字节
client: 192.168.3.218：客户端真实 IP（不是 47.104.152.64）
upstream: "192.168.1.176:59001"：Nginx 主动连到 Windows 的源端口
bytes upstream:122/103：Nginx 转发给后端的字节数

三、Nginx HTTP 反代的 9 大 buffer 调优

常见 warning（Nginx error.log）：

1

an upstream response is buffered to a temporary file

原因：Nginx 默认的 buffer 太小，每个请求的缓存不够，请求头 header 太大或响应体超过 buffer 时，写入磁盘临时文件，造成 IO 飙升，访问卡顿。

3.1 完整 buffer 配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


http {
 # client body（上传）
 client_max_body_size 2048m; # 最大上传 2GB
 client_body_buffer_size 1024k; # body 缓冲 1MB
 
 # proxy buffer
 proxy_buffer_size 256k; # header 缓冲 256K
 proxy_buffering on; # 开启缓冲（默认 on）
 proxy_buffers 64 128k; # 64 个 128K 缓冲（共 8MB）
 proxy_busy_buffers_size 512k; # 忙缓冲 512K（不能 > proxy_buffers 总和/2）
 
 # FastCGI buffer（PHP-FPM）
 fastcgi_buffer_size 512k; # header 缓冲
 fastcgi_buffers 6 512k; # 6 个 512K 缓冲（共 3MB）
 fastcgi_busy_buffers_size 512k; # 忙缓冲
 fastcgi_temp_file_write_size 512k; # 临时文件写入块大小
 fastcgi_intercept_errors on; # 拦截错误（4xx/5xx 自己处理）
}

3.2 各项调优解释

配置	作用	调优建议
`client_max_body_size`	最大请求体（POST 上传）	按业务定，文件上传建议 1g+
`client_body_buffer_size`	客户端 body 缓冲	16k ~ 1m
`proxy_buffer_size`	后端响应头缓冲	4k ~ 32k，大响应头可调到 128k
`proxy_buffers`	后端响应体缓冲（数量 × 单个大小）	通常 `8 16k` 或 `64 128k`
`proxy_busy_buffers_size`	正在发送的缓冲上限	必须 < `proxy_buffers` 总和的 1/2
`proxy_temp_file_write_size`	临时文件单次写入大小	默认 8k，调大可减少 IO 次数
`fastcgi_intercept_errors`	Nginx 拦截 FastCGI 错误	`on` 配合 `error_page` 自定义错误页

3.3 调优公式

总 buffer = proxy_buffer_size + proxy_buffers × 数量

例：proxy_buffers 64 128k = 64 × 128K = 8MB 单连接缓存

繁忙 buffer = proxy_busy_buffers_size × 2 ≤ 总 buffer

例：512k × 2 = 1MB ≤ 8MB ✓

四、Connection reset by peer 排错

完整错误：

1
2
3
4


recv() failed (104: Connection reset by peer) 
while proxying and reading from upstream, 
client: 89.248.163.87, server: 0.0.0.0:3399, 
upstream: "10.8.33.101:3389"

104 错误 = TCP RST，连接被对端强制关闭。

常见原因：

后端服务主动断开（如 Windows RDP 服务异常）
后端超时未响应，TCP keepalive 触发 RST
后端资源耗尽（CPU 100%、连接数打满）
Nginx 与后端的网络问题（中间设备丢包）

4.1 调优配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


upstream bigdata {
 server 10.0.20.1:18018;
 server 10.0.20.2:18018;
 server 10.0.20.3:18018;
 server 10.0.20.4:18018;
 keepalive 100; # Nginx 与上游保持的长连接数
}

location / {
 proxy_pass http://bigdata;
 
 # 加大超时（默认 60s 偏短）
 proxy_connect_timeout 120;
 proxy_send_timeout 120;
 proxy_read_timeout 120;
 
 # 关键：启用 HTTP/1.1 + 清理 Connection header
 proxy_http_version 1.1;
 proxy_set_header Connection "";
}

关键点：

配置	作用
`keepalive 100`	Nginx 与每个上游保持 100 个长连接（连接复用）
`proxy_http_version 1.1`	必须 1.1——HTTP/1.0 不支持 keep-alive
`proxy_set_header Connection ""`	清掉 `Connection: close`，让 keep-alive 生效

为什么 HTTP/1.1 + Connection "" 必加？

HTTP/1.0 的 Connection: keep-alive 是可选的，HTTP/1.1 默认 keep-alive 但 Connection: close 可以强制关闭。Nginx 默认往上游发的 Connection: close（不重用连接），所以必须显式清掉。

五、实战：MySQL stream 代理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


stream {
 upstream mysql_pool {
 server 10.0.0.10:3306;
 server 10.0.0.11:3306;
 }
 
 server {
 listen 33306;
 proxy_pass mysql_pool;
 proxy_connect_timeout 5s;
 proxy_timeout 600s;
 }
}

客户端连接：

1

mysql -h <nginx-ip> -P 33306 -u root -p

注意：MySQL 认证是基于 IP 的，代理后所有客户端都是 nginx-ip，可能触发 host 'nginx-ip' is not allowed。对策：

MySQL 授权时用 'root'@'%'
或在 MySQL 端用 skip-name-resolve

六、实战：Redis stream 代理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


stream {
 upstream redis_pool {
 server 10.0.0.10:6379;
 }
 
 server {
 listen 36379;
 proxy_pass redis_pool;
 proxy_connect_timeout 5s;
 proxy_timeout 300s;
 }
}

Redis 协议简单，stream 代理几乎零问题。

七、SSL/TLS over stream

stream 块也支持 SSL（需 --with-stream_ssl_module）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


stream {
 upstream mysql_ssl {
 server 10.0.0.10:3306;
 }
 
 server {
 listen 33307 ssl;
 proxy_pass mysql_ssl;
 ssl_certificate /etc/nginx/ssl/server.crt;
 ssl_certificate_key /etc/nginx/ssl/server.key;
 ssl_protocols TLSv1.2 TLSv1.3;
 }
}

典型场景：MySQL 客户端启 SSL，但不想让客户端直接连真实 MySQL，走 Nginx 反代统一证书。

八、负载均衡算法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


upstream backend {
 # 1. 轮询（默认）
 # server 10.0.0.10:8080;
 # server 10.0.0.11:8080;
 
 # 2. 加权轮询
 # server 10.0.0.10:8080 weight=3;
 # server 10.0.0.11:8080 weight=1;
 
 # 3. ip_hash（会话保持）
 # ip_hash;
 # server 10.0.0.10:8080;
 # server 10.0.0.11:8080;
 
 # 4. consistent hash（一致性 hash，加减节点影响小）
 hash $remote_addr consistent;
 server 10.0.0.10:8080;
 server 10.0.0.11:8080;
 
 # 5. least_conn（最闲）
 # least_conn;
 # server 10.0.0.10:8080;
 
 # 6. random
 # random;
}

九、健康检查与失败处理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


upstream backend {
 server 10.0.0.10:8080 max_fails=3 fail_timeout=30s;
 server 10.0.0.11:8080 max_fails=3 fail_timeout=30s;
 # 健康检查：失败 3 次标记为 down，30 秒后再试
}

server {
 listen 80;
 proxy_pass backend;
 proxy_next_upstream error timeout invalid_header http_502 http_503;
 # 后端 error/timeout/502/503 时，自动切到下一个 upstream
 proxy_next_upstream_tries 2;
 proxy_next_upstream_timeout 10s;
}

max_fails 与 fail_timeout：

30 秒内失败 3 次 → 标记 down
30 秒后再尝试（如果还失败，继续 down）

proxy_next_upstream：

error：连接错误
timeout：超时
invalid_header：响应头无效
http_502/503/504：HTTP 错误码
off：禁用

十、常见错误

10.1 stream 块识别为 HTTP

症状：Nginx 启动报 unknown directive "stream"。

原因：编译时没加 --with-stream。

对策：重编译 nginx 加 --with-stream，参考 1.1 节。

10.2 listen 端口冲突

1

bind() to 0.0.0.0:3399 failed (98: Address already in use)

对策：

1
2
3


ss -tan | grep 3399
# 看哪个进程占用
lsof -i :3399

10.3 客户端真实 IP 丢失

默认情况：后端看到的客户端 IP 是 Nginx 内网 IP（不是真实客户端）。

对策（仅限 HTTP，TCP 协议做不到）：

1
2
3
4
5


location / {
 proxy_pass http://backend;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

stream 块没有 proxy_set_header！要传真实 IP 必须用应用层协议（如 HTTP 的 X-Forwarded-For、MySQL 的账号 IP 白名单）。

10.4 大量 TIME_WAIT

症状：netstat -an | grep TIME_WAIT | wc -l 几万。

对策：

1
2
3
4
5


# 开启 TIME_WAIT 复用
sysctl -w net.ipv4.tcp_tw_reuse=1

# 缩短 TIME_WAIT 时间（默认 60s）
sysctl -w net.ipv4.tcp_fin_timeout=30

小结

Nginx stream 模块让 Nginx 从七层反代进化为"四/七层通吃"：

编译加 --with-stream
stream 块与 http 同级
listen + proxy_pass 简单粗暴
keepalive + HTTP/1.1 + Connection "" 是 HTTP 反代性能关键
buffer 调优避免写临时文件
客户端真实 IP（四层）传不到后端，靠应用层协议

生产建议：

七层反代：用 Nginx，配置友好
四层 1w-5w QPS：用 Nginx stream
四层 5w+ QPS：用 LVS DR 或 HAProxy
多协议混合：Nginx 统一管（HTTP 在 http 块，TCP 在 stream 块）

下一步：

用 Nginx stream + Let’s Encrypt 做 TLS 反代
上 HAProxy 做更细的健康检查
用 Envoy / APISIX 做云原生时代的四/七层代理

2024 视角：Nginx 仍是 1.25+ / 1.27+ 时代的王者

2013 那篇的 ngx_stream_core_module 仍是 Nginx 的核心特性。2024 视角下：

一、Nginx 1.25 / 1.27（2024 主流）

Nginx 1.25.x（2023-05 起的 mainline）：实验新特性。
Nginx 1.27.x（2024-08）：新 mainline，引入 HTTP/3 over QUIC 完整支持。
Nginx Plus R32（2024）：商业版新增 Dynamic Configuration via API、Active Health Checks 增强。

1
2
3


# 看版本
nginx -v
# nginx version: nginx/1.27.0

二、QUIC / HTTP/3 已成"必选项"

2013 那篇完全没提 QUIC。2024 视角下 QUIC / HTTP/3 已是性能优化标配：
- 握手 0-RTT（比 TLS 1.3 还快）
- 连接迁移（IP 变化不重连）
- 多路复用（解决 HTTP/2 队头阻塞）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# Nginx 1.25+ 启用 HTTP/3
server {
 listen 443 ssl;
 http2 on;
 
 # 启用 HTTP/3（同时监听 UDP 443）
 add_header Alt-Svc 'h3=":443"; ma=86400';
 
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_early_data on;
 ssl_protocols TLSv1.3;
}

# Nginx 1.27+ 直接
server {
 listen 443 quic reuseport;
 listen 443 ssl;
 http2 on;
 add_header Alt-Svc 'h3=":443"; ma=86400';
}

三、buffer 调优的"现代"配方

2013 那篇给的 proxy_buffer_size 256k / proxy_buffers 64 128k 仍是有效。
2024 实践：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 大文件 / 视频流
proxy_buffer_size 1m;
proxy_buffers 8 1m; # 8 个 1M（共 8M）
proxy_busy_buffers_size 2m;
proxy_temp_file_write_size 4m;

# API 服务（小响应）
proxy_buffer_size 16k;
proxy_buffers 8 16k;
proxy_busy_buffers_size 32k;

新指令：
- proxy_socket_keepalive on：向上游发 TCP keep-alive（避免 TIME_WAIT 堆积）
- proxy_pass_request_body off：透传大 body 优化
- proxy_force_ranges on：强制 Range 支持

四、`Connection reset by peer` 的 2024 排查清单

2013 那篇给的 proxy_http_version 1.1 + Connection "" + keepalive 100 仍是标准动作。2024 升级：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


upstream backend {
 server 10.0.20.1:18018 resolve;
 server 10.0.20.2:18018 resolve;
 keepalive 32; # 适当调小（旧值 100 过大）
 keepalive_requests 1000; # 单连接最多 1000 请求后关闭（防内存泄漏）
 keepalive_timeout 60s;
}

location / {
 proxy_pass http://backend;
 proxy_http_version 1.1;
 proxy_set_header Connection "";
 proxy_connect_timeout 5s; # 比 120s 短
 proxy_send_timeout 60s;
 proxy_read_timeout 60s;
 proxy_socket_keepalive on; # 2024 新
 proxy_next_upstream error timeout http_502 http_503;
 proxy_next_upstream_tries 2;
}

新调试工具：
- nginx -T：dump 完整配置（include 全部展开）
- error.log debug：详细 debug 日志
- stub_status：基础统计
- /usr/lib/nginx/modules/ngx_http_vhost_traffic_status（淘宝开源）：流量详情

五、stream 块在 K8s 时代的"角色"

2024 趋势：Nginx stream 在 K8s 时代被 Envoy 替代。
Nginx Ingress Controller（K8s 标准 Ingress 实现）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# k8s-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: myapp
 annotations:
 nginx.ingress.kubernetes.io/proxy-body-size: "50m"
 nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
spec:
 ingressClassName: nginx
 rules:
 - host: myapp.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: myapp
 port:
 number: 80

优势：Nginx Ingress Controller = Nginx + K8s 自动化（自动 reload、自动证书、自动 upstream）。

六、动态 upstream 的"现代"实现

2013 那篇的 upstream 是静态配置。
2024 现代姿势：upstream {} 动态解析（DNS + Service Discovery）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 动态 upstream（Nginx Plus 特性，开源版部分支持）
upstream backend {
 zone backend 64k;
 server backend-service.default.svc.cluster.local:80 resolve;
 resolver kube-dns.kube-system.svc.cluster.local valid=30s;
}

# 通过 API 动态加 backend
curl -X POST http://127.0.0.1:8080/api/version/http/upstreams/backend/servers/ \
 -d '{"server":"10.0.1.50:80"}'

Nginx 开源版（1.27+）也支持 resolver + resolve 指令，SVC 后端自动发现。

七、SSL/TLS 的"现代"最佳实践

2013 那篇的 ssl_protocols TLSv1 TLSv1.1 TLSv1.2 已经被2024 安全规范淘汰。
2024 强制：

1
2
3
4
5
6
7
8


ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;

OCSP Stapling：减少客户端验证延迟
TLS 1.3 强制：禁用 TLS 1.0/1.1

八、Nginx + 服务网格的"混合部署"

2024 大量 K8s 项目不再用 Nginx 反代——用 Istio / Linkerd 自带 Envoy。
Nginx 仍在用的场景：
- 边缘节点（CDN 边缘）
- 物理机 / 虚拟机（不在 K8s 里）
- Web 服务器（静态资源）
- API 网关（Apigee / Kong 基于 Nginx）
- Sidecar 替代（轻量场景，Nginx sidecar 比 Envoy 资源占用更少）

九、Nginx 商业替代

F5 NGINX Plus（商业版）：Dynamic Configuration API、Active Health Checks、JWT 验证、WAF
OpenResty（章亦春）：Lua 脚本扩展——2024 仍是国内"高阶 Nginx 玩法"主流
Caddy：自动 HTTPS（Let’s Encrypt 内置）
Traefik：云原生时代的"动态 Nginx"

源文档：

os/linux/第三方tools/dev/反向代理/Nginx/nginx.md（stream TCP 代理 + 自定义日志）
os/linux/第三方tools/dev/反向代理/Nginx/问题.md（buffer 调优 + Connection reset by peer）