Trustivon VPN 是一款企业级区块链基础设施安全接入管理方案，基于 OpenVPN 协议开发，为企业服务提供安全网络访问控制。系统采用 Web 可视化管理界面，支持多种认证方式，提供完善的用户管理、连接监控和审计功能。
随着远程办公、跨地域访问与隐私保护需求的不断增长，VPN（虚拟专用网络）正在成为个人与企业必备的基础设施之一。而传统的 WireGuard VPN 配置流程对于普通用户而言存在一定门槛，需要大量命令行操作与手动配置。WG-Easy 正是在这种背景下应运而生的高效解决方案，它将 WireGuard 的强大性能与可视化管理相结合，大大降低部署和维护难度。
WG-Easy（WireGuard Easy） 是一个将 WireGuard VPN 核心服务与 Web 可视化管理界面深度集成的开源项目。它通过直观的浏览器操作界面，让用户无需掌握复杂的命令行知识，即可快速完成 VPN 的部署、配置与监控。
设计理念：
Web 界面完成，告别配置文件WireGuard 协议，提供媲美直连的网络速度WireGuard Easy 提供了一套完整的 VPN 管理功能,主要特性包括:
VPN 与 Web 管理界面整合在一起。Docker 容器化，一条命令即可启动完整 VPN 服务。Prometheus，便于接入 Grafana 统一监控体系。在部署前，请确认服务器内核已支持 WireGuard：
uname -r加载 WireGuard 内核模块：
modprobe wireguard验证是否成功：
lsmod | grep wireguard说明：
- Linux Kernel ≥ 5.6 已内置 WireGuard
- Ubuntu 20.04+ / 22.04 LTS 默认支持
- 若加载失败，请检查内核版本或云厂商是否裁剪模块
配置防火墙规则
# Ubuntu/Debian (使用 ufw)
sudo ufw allow 51820/udp comment 'WireGuard VPN'
sudo ufw allow 51821/tcp comment 'WG-Easy Web UI'若云厂商启用防火墙 / 安全组，务必同步放行端口。
docker network create \
-d bridge --ipv6 \
--subnet 10.42.42.0/24 \
--subnet fdcc:ad94:bacf:61a3::/64 \
wgdocker run -d \
--net wg \
-e INSECURE=true \
--name wg-easy \
--ip6 fdcc:ad94:bacf:61a3::2a \
--ip 10.42.42.42 \
-v ~/.wg-easy:/etc/wireguard \
-v /lib/modules:/lib/modules:ro \
-p 51820:51820/udp \
-p 51821:51821/tcp \
--cap-add NET_ADMIN \
--cap-add SYS_MODULE \
--sysctl net.ipv4.ip_forward=1 \
--sysctl net.ipv4.conf.all.src_valid_mark=1 \
--sysctl net.ipv6.conf.all.disable_ipv6=0 \
--sysctl net.ipv6.conf.all.forwarding=1 \
--sysctl net.ipv6.conf.default.forwarding=1 \
--restart unless-stopped \
ghcr.io/wg-easy/wg-easy:15访问浏览器 http://服务器IP:51821 即可进入界面。
# Ubuntu/Debian
# sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo apt install -y docker-compose-pluginmkdir ~/wg-easy/ && mkdir ~/wg-easy/sudo curl -o /etc/docker/containers/wg-easy/docker-compose.yml https://raw.githubusercontent.com/wg-easy/wg-easy/master/docker-compose.ymldocker-compose.yml文件并取消environment注释INSECUREINSECURE为true允许通过非安全http连接访问 Web UI。完整docker-compose.yml文件如下：
volumes:
etc_wireguard:
services:
wg-easy:
volumes:
etc_wireguard:
services:
wg-easy:
environment:
- INSECURE=true
image: ghcr.nju.edu.cn/wg-easy/wg-easy:15
container_name: wg-easy
networks:
wg:
ipv4_address: 10.42.42.42
ipv6_address: fdcc:ad94:bacf:61a3::2a
volumes:
- etc_wireguard:/etc/wireguard
- /lib/modules:/lib/modules:ro
ports:
- "51820:51820/udp"
- "51821:51821/tcp"
restart: unless-stopped
cap_add:
- NET_ADMIN
- SYS_MODULE
sysctls:
- net.ipv4.ip_forward=1
- net.ipv4.conf.all.src_valid_mark=1
- net.ipv6.conf.all.disable_ipv6=0
- net.ipv6.conf.all.forwarding=1
- net.ipv6.conf.default.forwarding=1
networks:
wg:
driver: bridge
enable_ipv6: true
ipam:
driver: default
config:
- subnet: 10.42.42.0/24
- subnet: fdcc:ad94:bacf:61a3::/64# 启动容器
docker compose up -d
# 查看日志
docker compose logs -f wg-easy
# 查看容器状态
docker compose ps访问浏览器 http://服务器IP:51821 即可进入界面。
修改客户端配置，添加允许的 IP ，决定哪些流量走 VPN：
# 全局代理（所有流量走 VPN）
0.0.0.0/0, ::/0
# 仅访问特定网段（分流模式，推荐）
10.42.42.0/24 # WireGuard 内网
10.7.0.0/22 # 服务器内网
172.17.0.0/24 # docker
192.168.1.0/24 # 家庭网络分流模式的优势：
保存后即可通过扫描二维码或下载配置文件连接。
进入 管理面板 > 通用设置 > Prometheus，启用监控并设置密码。
在 Prometheus 配置文件中添加：以下是一个示例：
scrape_configs:
- job_name: 'wg-easy'
scrape_interval: 30s
metrics_path: /metrics/prometheus
static_configs:
- targets:
- '服务器IP:51821'
authorization:
type: Bearer
credentials: '上一步设置的密码'
Grafana Dashboard ID：21733
WG-Easy 适用于多种实际应用场景，从个人隐私保护到企业级远程访问，都能提供高效的解决方案：
远程办公 / 内网访问
安全访问公司内网服务（Git、Jenkins、数据库、K8s 等）。
跨地域统一出口网络
多终端统一出口 IP，便于访问特定区域网络资源。
家庭网络远程访问
安全访问家中 NAS、路由器、智能家居设备、监控摄像头、内网服务。
小型团队 VPN 管理
无需专业网络运维即可维护团队 VPN。
测试 / 沙箱 / 运维环境
快速搭建临时 VPN，随用随删，配置可追溯。
| 平台 | 下载地址 |
|---|---|
| Windows | https://download.wireguard.com/windows-client/ |
| macOS | https://apps.apple.com/app/wireguard/id1451685025 |
| Android | https://play.google.com/store/apps/details?id=com.wireguard.android |
| iOS | https://apps.apple.com/app/wireguard/id1441195209 |
| Linux | sudo apt install wireguard 或各发行版包管理器 |
| 对比维度 | WireGuard | IPsec | OpenVPN |
|---|---|---|---|
| 协议架构 | 第3层 VPN，内核态，仅 UDP | 第3层 VPN 协议族，内核态 | 应用层 SSL/TLS，用户态，TCP/UDP |
| 加密方案 | 固定现代套件（ChaCha20-Poly1305） | 可配置（AES、3DES 等） | 可配置（默认 AES-256-GCM） |
| 认证方式 | 公钥认证 | 预共享密钥、证书、EAP | 证书、用户名密码、双因素 |
| 安全性 | 高（现代密码学，代码简洁易审计） | 较高（成熟可靠但配置复杂） | 较高（依赖 OpenSSL） |
| 性能 | 极高（低延迟，高吞吐） | 高性能 | 中等 |
| 资源占用 | 极低（CPU，内存） | 低到中等 | 中等到高 |
| 连接速度 | 几乎即时 | 较慢（需要协商） | 快速 |
| 配置难度 | 极简（少量配置） | 复杂 | 中等 |
| NAT 穿透 | 优秀 | 良好 | 优秀 |
| 防火墙穿透 | 良好（UDP 可能受限） | 一般（ESP 常被阻断） | 极佳（可伪装 HTTPS） |
| 移动网络切换 | 无感知漫游 | 需要重连 | 较好 |
| 网络拓扑 | 点对点，站点互联，Mesh 网络 | 站点互联，远程访问 | 远程访问，点对点 |
| 平台支持 | Linux，Windows，macOS，iOS，Android，路由器 | 全平台原生支持 | 全平台完整支持 |
| 企业成熟度 | 快速增长中 | 广泛企业级应用 | 广泛企业级应用 |
| 合规认证 | 较少 | 完善（FIPS 等） | 多种认证 |
| 适用场景 | 个人 VPN，移动办公，物联网 | 企业站点互联，高合规场景 | 企业远程访问，严格防火墙 |
WG-Easy 以其实用性和易用性，大幅降低了传统 WireGuard VPN 的部署门槛，使 VPN 架构不仅对开发者友好，也对非专业用户易于使用。
无论是个人自建 VPN，还是企业内网 VPN 管理，WG-Easy 都能提供简洁，高效，安全的解决方案，是非常值得推荐的开源 VPN 工具。
在现代互联网时代，数据安全、隐私保护和远程接入已成为企业与个人网络部署的核心需求。传统 VPN 解决方案在保障网络通信安全方面发挥了重要作用，而随着容器化技术的成熟，将 VPN 服务以 Docker 方式部署并结合 Web UI 管理，正成为自建网络服务的新趋势。
GavinTan/openvpn 是一个基于Docker容器化部署的OpenVPN服务器项目，旨在通过直观的 Web 管理界面简化 VPN 管理。该解决方案提供对用户账户管理、客户端管理、证书管理、服务器配置和实时连接监控的集中控制，同时通过多因素身份验证和 LDAP 集成保持企业级安全性。
项目提供了完善的用户管理系统,支持本地账号和LDAP集成两种认证方式:
admin/admin,首次登录后可修改密码VPN账号,每个账号可独立管理VPN用户可以登录专属页面,自行下载配置文件、修改密码、设置MFALDAP后可与企业现有的账号体系打通,实现统一认证作为VPN的核心安全组件,证书管理功能设计得非常周到:
项目在网络协议支持方面非常全面:
IPv6支持,适应现代网络环境安全性是VPN最核心的要求,项目在这方面做得很扎实:
MFA):支持基于时间的一次性密码(TOTP),大幅提升账号安全性LDAP集成:可与企业Active Directory或OpenLDAP集成友好的监控功能让问题排查变得简单:
server.conf配置文件针对不同的使用场景,项目提供了灵活的网络配置选项:
在开始部署前,请确保你的服务器满足以下要求:
这是最简单的部署方式,适合快速测试和小规模使用:
# 创建数据目录
mkdir-p~/openvpn-data
# 启动容器
dockerrun-d\
--nameopenvpn\
--cap-add=NET_ADMIN\
-p1194:1194/udp\
-p8833:8833\
-v~/openvpn-data:/data\
-v/etc/localtime:/etc/localtime:ro\
docker.1ms.run/yyxx/openvpn参数说明:
--cap-add=NET_ADMIN:赋予容器网络管理权限,OpenVPN必需-p 1194:1194/udp:映射VPN服务端口(UDP协议)-p 8833:8833:映射Web管理界面端口-v ~/openvpn-data:/data:持久化数据目录,包含配置、证书等重要文件-v /etc/localtime:/etc/localtime:ro:同步系统时间,确保日志时间准确对于生产环境,推荐使用Docker Compose,便于管理和维护:
# CentOS/RHEL
yum install -y docker-compose-plugin
# Ubuntu/Debian
apt install -y docker-compose-pluginmkdir ~/openvpn&&cd~/openvpn
cat>docker-compose.yml<<'EOF'
services:
openvpn:
image:docker.1ms.run/yyxx/openvpn
container_name:openvpn
restart:unless-stopped
cap_add:
-NET_ADMIN
ports:
-"1194:1194/udp"
-"8833:8833"
volumes:
-./data:/data
-/etc/localtime:/etc/localtime:ro
EOFdocker compose up -ddocker compose logs -f openvpn如果你的网络环境支持IPv6,可以启用IPv6功能:
services:
openvpn:
image:docker.1ms.run/yyxx/openvpn
container_name:openvpn
restart:unless-stopped
cap_add:
-NET_ADMIN
ports:
-"1194:1194/udp"
-"8833:8833"
volumes:
-./data:/data
-/etc/localtime:/etc/localtime:ro
sysctls:
-net.ipv6.conf.default.disable_ipv6=0
-net.ipv6.conf.all.forwarding=1
networks:
default:
enable_ipv6:trueIPv6使用注意事项:
服务启动后,按以下步骤完成初始化:
第一步:登录管理界面
http://服务器IP:8833admin,密码admin第二步:生成客户端配置
管理" → "客户端"页面第三步:创建VPN账号
管理" → "VPN账号"页面第四步:客户端连接测试
OpenVPN客户端软件，用第三步创建账号访问http://服务器IP:8833下载对应平台软件对于企业用户,可以集成LDAP实现统一认证:
uidsAMAccountNameldaps://ldap.example.com:636注意:启用LDAP后,本地VPN账号将不再工作,所有认证都通过LDAP进行。
docker logs openvpn这是最常见的问题!原因是没有配置路由推送。
解决方案:
在Web界面【管理】-->【配置文件】查看 server.conf 配置中是否有类似内容:
push "dhcp-option DNS 8.8.8.8"
push "route 10.0.12.0 255.255.252.0"
push "route 172.17.0.0 255.255.0.0"
push "route 10.100.100.0 255.255.255.0"sysctl net.ipv4.ip_forward
# 应该返回: net.ipv4.ip_forward = 1iptables -t nat -L -n
# 应该看到 MASQUERADE 规则修改配置后,客户端必须断开重连才能获取新路由
按需添加,不要一股脑全加!判断方法:
# 1. 查看服务器网卡信息
ip addr show
# 2. 确定你要访问的目标
# - 只访问服务器本机? → 只加服务器内网网段
# 云服务器内网路由
push "route 10.0.12.0 255.255.252.0"
# - 要访问ZeroTier设备? → 加ZeroTier网段
push "route 10.100.100.0 255.255.255.0"
# - 要访问Docker容器内部? → 加Docker网段
push "route 172.17.0.0 255.255.0.0"
# 3. 使用最小配置原则
# 先加最必要的,测试通过后再按需添加逐步排查:
# 1. 在客户端检查路由表
# Windows: route print
# Mac/Linux: netstat -rn
# 2. 测试连通性
ping 10.8.0.1 # 测试VPN网关
ping 10.0.12.12 # 测试服务器IP
traceroute 10.0.12.12 # 查看路由路径
# 3. 检查防火墙
# 确认服务器和客户端防火墙都允许相关流量
对于需要访问开发环境的团队:
连锁企业或多分支机构可以:
对于注重网络隐私的个人用户:
网络安全从业者可以:
这是最常见的个人使用场景:
需求: 外出时访问家里的NAS、监控、智能家居
架构方案:
手机(外网) → OpenVPN(云服务器) → ZeroTier/EasyTier → 家里设备路由配置:
# OpenVPN配置
push "route 10.100.100.0 255.255.255.0" # ZeroTier网段
# 家里的NAS、路由器、摄像头都在这个网段实际效果:
http://10.244.244.5:5000 (家里NAS)http://10.244.244.6:8080 (家里监控)为什么不直接用ZeroTier?
该项目是一款结合了 Docker 部署与 Web 管理 UI 的 OpenVPN 解决方案，既保留了 OpenVPN 强大的网络安全能力，又通过 Web 界面降低了部署和维护门槛。对于希望快速构建自有 VPN 平台或希望在内部网络中实现便捷远程访问管理的团队和个人开发者，该项目是一种高效实用的方案。
说实话，Nginx调优这事儿我踩过无数坑。记得2019年双11，我们电商平台流量暴涨，Nginx直接扛不住了，QPS从平时的2万飙升到8万，响应时间从50ms飙到了2秒，最后还是靠临时加机器扛过去的。那次事故之后，我花了大半年时间专门研究Nginx的性能极限，总结出了这20条黄金法则。
Nginx作为目前最流行的Web服务器和反向代理，官方数据显示单机可以轻松处理10万+的并发连接。但实际生产环境中，很多同学拿到默认配置就直接上了，结果发现连1万并发都扛不住。问题不在Nginx本身，而在于配置。
Nginx采用事件驱动的异步非阻塞架构，这跟传统的Apache每个连接一个进程/线程的模式完全不同。打个比方：Apache像是银行柜台，每个客户都需要一个柜员全程服务；Nginx则像是叫号系统，一个柜员可以同时处理多个客户的不同阶段任务。
核心优势：
| 组件 | 版本 | 说明 |
|---|---|---|
| 操作系统 | Rocky Linux 9.4 / Ubuntu 24.04 LTS | 内核版本建议5.15+ |
| Nginx | 1.26.2 / 1.27.0 | mainline版本功能更新，stable版本更稳定 |
| CPU | 8核+ | Nginx worker数量与CPU核心数相关 |
| 内存 | 16GB+ | 主要用于连接缓冲和缓存 |
| 网络 | 万兆网卡 | 千兆网卡在高并发下会成为瓶颈 |
| 磁盘 | NVMe SSD | 日志写入和缓存需要高IOPS |
在动Nginx配置之前，得先把操作系统底子打好。很多人忽略了这一步，结果Nginx配得再好也白搭。
# /etc/sysctl.conf 追加以下内容
# 文件描述符限制
fs.file-max = 2097152
fs.nr_open = 2097152
# TCP连接相关
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_max_syn_backlog = 65535
# TIME_WAIT优化（这个参数救过我无数次）
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_tw_buckets = 262144
# TCP keepalive
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3
# 网络缓冲区
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 本地端口范围
net.ipv4.ip_local_port_range = 1024 65535应用配置：
sysctl -p这是个老生常谈的问题了，但每次接手新项目还是会遇到。Nginx报"Too many open files"错误，十有八九就是这个没配好。
# /etc/security/limits.conf
* soft nofile 1048576
* hard nofile 1048576
nginx soft nofile 1048576
nginx hard nofile 1048576
# /etc/systemd/system/nginx.service.d/override.conf
[Service]
LimitNOFILE=1048576# 自动检测CPU核心数，省心省力
worker_processes auto;
# 或者手动指定，建议等于CPU核心数
# worker_processes 8;
# CPU亲和性绑定，减少CPU缓存失效
worker_cpu_affinity auto;踩坑记录：早期我喜欢把worker_processes设成CPU核心数的2倍，觉得这样能处理更多请求。结果发现这是典型的过度优化，多出来的worker进程反而增加了上下文切换开销，QPS不升反降。
events {
# 每个worker的最大连接数
# 理论最大并发 = worker_processes * worker_connections
worker_connections 65535;
# 使用epoll事件模型（Linux 2.6+必选）
use epoll;
# 允许一个worker进程同时接受多个新连接
multi_accept on;
# 互斥锁，高并发场景建议关闭
accept_mutex off;
}# main context
worker_rlimit_nofile 1048576;http {
# 开启sendfile，避免用户态和内核态之间的数据拷贝
sendfile on;
# 配合sendfile使用，减少网络报文段数量
tcp_nopush on;
# 禁用Nagle算法，减少延迟
tcp_nodelay on;
}原理解释：传统文件发送需要经历"磁盘->内核缓冲区->用户缓冲区->socket缓冲区"四次拷贝。sendfile直接在内核态完成"磁盘->socket缓冲区"的数据传输，理论上可以提升30%-40%的吞吐量。
http {
# 客户端请求头超时
client_header_timeout 15s;
# 客户端请求体超时
client_body_timeout 15s;
# 响应超时
send_timeout 15s;
# keepalive超时
keepalive_timeout 65s;
# keepalive请求数量限制
keepalive_requests 10000;
}踩坑记录：曾经有个项目，上传大文件总是失败。排查半天发现是client_body_timeout设成了10秒，但大文件上传需要更长时间。生产环境这个值建议根据实际业务调整，不要一刀切。
http {
# 客户端请求体缓冲区
client_body_buffer_size 128k;
client_max_body_size 100m;
# 请求头缓冲区
client_header_buffer_size 4k;
large_client_header_buffers 4 32k;
# 代理缓冲区
proxy_buffer_size 64k;
proxy_buffers 8 128k;
proxy_busy_buffers_size 256k;
}http {
gzip on;
gzip_vary on;
gzip_proxied any;
# 压缩级别1-9，建议4-6，太高CPU消耗大
gzip_comp_level 5;
# 最小压缩长度，太小的文件压缩反而浪费CPU
gzip_min_length 1024;
# 压缩类型
gzip_types
text/plain
text/css
text/javascript
application/javascript
application/json
application/xml
application/xml+rss
image/svg+xml;
# 预压缩文件支持
gzip_static on;
}性能对比：
| 压缩级别 | 压缩率 | CPU消耗 | 适用场景 |
|---|---|---|---|
| 1 | 低 | 最低 | CPU受限环境 |
| 4-5 | 中 | 中等 | 通用场景（推荐） |
| 9 | 高 | 最高 | 带宽极其昂贵 |
http {
# 打开文件缓存
open_file_cache max=100000 inactive=60s;
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
}
server {
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ {
expires 30d;
add_header Cache-Control "public, immutable";
access_log off;
}
}http {
# 使用缓冲写入，减少磁盘IO
access_log /var/log/nginx/access.log main buffer=64k flush=5s;
# 或者对于高并发场景，考虑关闭access log
# access_log off;
# 错误日志级别
error_log /var/log/nginx/error.log warn;
}血泪教训：生产环境日志不要开debug级别！我曾经为了排查问题临时开了debug，结果磁盘一会儿就满了，服务直接挂掉。
http {
# SSL会话缓存
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets on;
# SSL协议版本
ssl_protocols TLSv1.2 TLSv1.3;
# 优先使用服务器端加密套件
ssl_prefer_server_ciphers off;
# TLS 1.3加密套件
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
}server {
listen 443 ssl;
http2 on;
# HTTP/2推送（Nginx 1.25.1+）
# 注意：主流浏览器已逐步废弃Server Push
}upstream backend {
server 10.0.0.1:8080;
server 10.0.0.2:8080;
# 与后端保持的连接数
keepalive 300;
# 单个连接最大请求数
keepalive_requests 10000;
# 连接超时
keepalive_timeout 60s;
}
server {
location /api/ {
proxy_pass http://backend;
# 必须使用HTTP/1.1才能使用keepalive
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}这条救命配置：很多人配了upstream的keepalive但不生效，99%是因为没加proxy_set_header Connection ""。默认情况下Nginx会把Connection头设成close，导致每次请求都新建连接。
upstream backend {
# 最少连接数算法，推荐
least_conn;
# 或者IP哈希（需要会话保持时使用）
# ip_hash;
# 或者一致性哈希
# hash $request_uri consistent;
server 10.0.0.1:8080 weight=3;
server 10.0.0.2:8080 weight=2;
server 10.0.0.3:8080 weight=1 backup;
}upstream backend {
server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
}开源版Nginx的健康检查比较弱，只能被动检测。如果需要主动健康检查，建议：
http {
# 定义限流区域
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
}
server {
location /api/ {
# 请求速率限制
limit_req zone=api_limit burst=200 nodelay;
# 并发连接限制
limit_conn conn_limit 50;
# 限流返回码
limit_req_status 429;
limit_conn_status 429;
}
}location /api/ {
proxy_pass http://backend;
# 连接超时
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
# 失败重试
proxy_next_upstream error timeout http_502 http_503;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 10s;
# 请求头传递
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}http {
# 定义缓存路径
proxy_cache_path /var/cache/nginx levels=1:2
keys_zone=api_cache:100m
max_size=10g
inactive=60m
use_temp_path=off;
}
server {
location /api/public/ {
proxy_pass http://backend;
proxy_cache api_cache;
proxy_cache_valid 200 10m;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout updating;
proxy_cache_lock on;
add_header X-Cache-Status $upstream_cache_status;
}
}http {
# 隐藏版本号
server_tokens off;
# 安全响应头
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}
server {
# 禁止访问隐藏文件
location ~ /\. {
deny all;
access_log off;
log_not_found off;
}
}server {
listen 127.0.0.1:8080;
location /nginx_status {
stub_status on;
allow 127.0.0.1;
deny all;
}
}# 检查配置文件语法
nginx -t
# 平滑重载配置
nginx -s reload
# 或者使用systemd
systemctl reload nginx# 检查配置
nginx -t
# 启动服务
systemctl start nginx
systemctl enable nginx
# 验证运行状态
systemctl status nginx
curl -I http://localhost这是一份经过实战检验的完整配置，适用于10万并发场景：
# /etc/nginx/nginx.conf
user nginx;
worker_processes auto;
worker_cpu_affinity auto;
worker_rlimit_nofile 1048576;
error_log /var/log/nginx/error.log warn;
pid /run/nginx.pid;
events {
worker_connections 65535;
use epoll;
multi_accept on;
accept_mutex off;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
# 日志格式
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'$request_time $upstream_response_time';
log_format json escape=json '{'
'"time":"$time_iso8601",'
'"remote_addr":"$remote_addr",'
'"method":"$request_method",'
'"uri":"$uri",'
'"status":$status,'
'"body_bytes_sent":$body_bytes_sent,'
'"request_time":$request_time,'
'"upstream_response_time":"$upstream_response_time"'
'}';
access_log /var/log/nginx/access.log main buffer=64k flush=5s;
# 基础优化
sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
# 超时配置
keepalive_timeout 65;
keepalive_requests 10000;
client_header_timeout 15;
client_body_timeout 15;
send_timeout 15;
# 缓冲区
client_body_buffer_size 128k;
client_max_body_size 100m;
client_header_buffer_size 4k;
large_client_header_buffers 4 32k;
# Gzip压缩
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css text/javascript
application/javascript application/json
application/xml image/svg+xml;
# 文件缓存
open_file_cache max=100000 inactive=60s;
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
# SSL优化
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
# 限流配置
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
# 代理缓存
proxy_cache_path /var/cache/nginx levels=1:2
keys_zone=api_cache:100m
max_size=10g
inactive=60m
use_temp_path=off;
# 上游服务器
upstream backend {
least_conn;
keepalive 300;
keepalive_requests 10000;
keepalive_timeout 60s;
server 10.0.0.1:8080 weight=3 max_fails=3 fail_timeout=30s;
server 10.0.0.2:8080 weight=3 max_fails=3 fail_timeout=30s;
server 10.0.0.3:8080 weight=2 max_fails=3 fail_timeout=30s;
}
# 虚拟主机配置
include /etc/nginx/conf.d/*.conf;
}背景：日均UV 500万，静态资源请求峰值QPS 5万
server {
listen 80;
listen 443 ssl;
http2 on;
server_name static.example.com;
ssl_certificate /etc/nginx/ssl/static.example.com.crt;
ssl_certificate_key /etc/nginx/ssl/static.example.com.key;
root /data/static;
# 图片资源
location ~* \.(jpg|jpeg|png|gif|webp|ico)$ {
expires 365d;
add_header Cache-Control "public, immutable";
add_header Vary Accept;
access_log off;
# WebP自动转换
set $webp "";
if ($http_accept ~* "webp") {
set $webp ".webp";
}
try_files $uri$webp $uri =404;
}
# CSS/JS资源
location ~* \.(css|js)$ {
expires 30d;
add_header Cache-Control "public, immutable";
access_log off;
}
# 字体资源
location ~* \.(woff|woff2|ttf|eot)$ {
expires 365d;
add_header Cache-Control "public, immutable";
add_header Access-Control-Allow-Origin *;
access_log off;
}
}效果：优化后平均响应时间从15ms降到3ms，带宽使用减少40%（Gzip功劳）。
背景：微服务架构，需要统一入口，QPS峰值3万
upstream user_service {
least_conn;
keepalive 100;
server 10.0.1.1:8080 max_fails=2 fail_timeout=10s;
server 10.0.1.2:8080 max_fails=2 fail_timeout=10s;
}
upstream order_service {
least_conn;
keepalive 100;
server 10.0.2.1:8080 max_fails=2 fail_timeout=10s;
server 10.0.2.2:8080 max_fails=2 fail_timeout=10s;
}
server {
listen 443 ssl;
http2 on;
server_name api.example.com;
ssl_certificate /etc/nginx/ssl/api.example.com.crt;
ssl_certificate_key /etc/nginx/ssl/api.example.com.key;
# 公共配置
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Connection "";
# 用户服务
location /api/v1/users {
limit_req zone=api_limit burst=50 nodelay;
proxy_pass http://user_service;
proxy_connect_timeout 3s;
proxy_read_timeout 30s;
}
# 订单服务
location /api/v1/orders {
limit_req zone=api_limit burst=100 nodelay;
proxy_pass http://order_service;
proxy_connect_timeout 3s;
proxy_read_timeout 60s;
}
# 健康检查
location /health {
access_log off;
return 200 'OK';
add_header Content-Type text/plain;
}
}split_clients $remote_addr $variant {
10% backend_new;
* backend_old;
}
location /api/ {
proxy_pass http://$variant;
}| 常见错误 | 原因分析 | 解决方案 |
|---|---|---|
| worker_connections不生效 | 系统文件描述符限制 | 检查ulimit -n和worker_rlimit_nofile |
| keepalive不生效 | 未设置proxy_http_version和Connection头 | 添加proxy_http_version 1.1和proxy_set_header Connection "" |
| Gzip不生效 | Content-Type未在gzip_types列表中 | 添加对应的MIME类型 |
| SSL握手慢 | 未启用session缓存 | 配置ssl_session_cache |
| 499错误多 | 客户端提前断开 | 检查后端响应时间，调整超时设置 |
| 502/504错误 | 后端超时或不可用 | 检查upstream健康状态，调整超时参数 |
# 检查Nginx进程状态
ps aux | grep nginx
# 查看监听端口
ss -tlnp | grep nginx
# 实时查看访问日志
tail -f /var/log/nginx/access.log
# 实时查看错误日志
tail -f /var/log/nginx/error.log
# 查看连接状态统计
ss -s
# 查看TIME_WAIT连接数
ss -ant | grep TIME-WAIT | wc -l
# 测试配置文件
nginx -t
# 查看编译参数
nginx -V# 使用wrk进行压力测试
wrk -t12 -c400 -d30s http://localhost/api/test
# 使用ab进行压力测试
ab -n 10000 -c 100 http://localhost/api/test
# 查看nginx_status
curl http://127.0.0.1:8080/nginx_status
# 输出示例：
# Active connections: 2341
# server accepts handled requests
# 12847123 12847123 45123847
# Reading: 12 Writing: 89 Waiting: 2240# 需要安装nginx-prometheus-exporter
# 配置stub_status后，使用exporter采集数据
server {
listen 127.0.0.1:8080;
location /nginx_status {
stub_status on;
allow 127.0.0.1;
deny all;
}
}Prometheus配置：
scrape_configs:
- job_name: 'nginx'
static_configs:
- targets: ['localhost:9113']| 指标 | 告警阈值 | 说明 |
|---|---|---|
| nginx_http_requests_total | - | 请求总数，用于计算QPS |
| nginx_connections_active | > 80% worker_connections | 活跃连接数 |
| nginx_connections_waiting | - | 等待连接数 |
| 5xx错误率 | > 1% | 服务端错误 |
| 平均响应时间 | > 500ms | 响应时间 |
| upstream响应时间 | > 1s | 后端响应时间 |
# 配置备份脚本
#!/bin/bash
BACKUP_DIR="/data/backup/nginx"
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p ${BACKUP_DIR}
tar -czf ${BACKUP_DIR}/nginx_${DATE}.tar.gz /etc/nginx/
# 保留最近30天备份
find ${BACKUP_DIR} -name "*.tar.gz" -mtime +30 -delete
# 恢复命令
tar -xzf ${BACKUP_DIR}/nginx_20250107_120000.tar.gz -C /
nginx -t && systemctl reload nginx这20条黄金法则覆盖了Nginx性能调优的方方面面：
实施这些优化后，我见证过的性能提升：
| 命令 | 说明 |
|---|---|
nginx -t |
测试配置文件语法 |
nginx -s reload |
平滑重载配置 |
nginx -s stop |
快速停止 |
nginx -s quit |
优雅停止 |
nginx -V |
查看编译参数 |
nginx -T |
输出完整配置 |
| 参数 | 默认值 | 推荐值 | 说明 |
|---|---|---|---|
| worker_processes | 1 | auto | worker进程数 |
| worker_connections | 512 | 65535 | 单worker最大连接数 |
| keepalive_timeout | 75s | 65s | 客户端keepalive超时 |
| keepalive_requests | 100 | 10000 | 单连接最大请求数 |
| client_max_body_size | 1m | 100m | 请求体最大值 |
| gzip_comp_level | 1 | 5 | Gzip压缩级别 |
| 术语 | 解释 |
|---|---|
| QPS | Queries Per Second，每秒查询数 |
| TPS | Transactions Per Second，每秒事务数 |
| Keepalive | 持久连接，复用TCP连接 |
| Upstream | 上游服务器，即后端服务 |
| Reverse Proxy | 反向代理 |
| Load Balancing | 负载均衡 |
| epoll | Linux高效的I/O事件通知机制 |
| Zero Copy | 零拷贝技术，减少数据拷贝次数 |
[submodule "libs/foo"]
path = libs/foo
url = https://github.com/old-org/foo.git改成：
[submodule "libs/foo"]
path = libs/foo
url = https://github.com/new-org/foo.gitgit submodule syncgit submodule update --init --recursivegit add .gitmodules
git commit -m "chore: update submodule foo url"
git pushgit remote -v你会看到类似：
origin https://github.com/old-org/project.git (fetch)
origin https://github.com/old-org/project.git (push)git remote set-url origin https://github.com/new-org/project.git验证
git remote -vgit push -u origin main
# 或
git push -u origin master