把生产环境当玩具，客户投诉让人头都麻了
见过整个运维部同时沉默的样子吗？ 一封客户的投诉邮件，措辞客气，但句句见血。看完两段，头都麻了。
不是什么业务故障、代码死锁，就两件“部署小事”。但恰恰是这两件小事，让我觉得有必要写篇文章，提醒一下同行。
信里有两点特别扎眼，今天拆开来聊一聊。
第一件：Nginx 跑在 Windows 上
平台上线前部署代理操作系统为什么是 windows？我工作这么多年，多多少少接触了上百家公司，用 Linux 的至少 50 家，50 家里面你们是我见过第一家在 windows 上部署 nginx 的……
说实话，读到这句的时候，我愣了一下，然后笑了，苦笑。
Nginx 这玩意儿，生下来就是为 Linux 活的。它的灵魂是 epoll——Linux 内核里那个处理高并发的神器。Windows 上虽然也有 IOCP，但 Nginx 官方对 Windows 的支持，定位从来都是 “开发测试” ，官网上白纸黑字，生产环境强烈推荐 Linux。
为什么还会有人把 Nginx 装给 Windows？
无非三种情况：
- 历史包袱太重，早期业务是 .NET/IIS，懒得迁，也不敢迁；
- 团队里没人熟 Linux，招不到人，也舍不得花钱招；
- 装上去能启动，没报错，就以为没事了。
但代价呢？
性能打折。 Windows 上的 Nginx 被迫退回到 select / poll 模型。虽然从 1.15.9 版本开始支持 poll 模型，可以绕过 select 的1024硬限制，但这只是“能跑”，远没到“跑得好”的程度。poll 在 Windows 上的实现本身就有缺陷，比如可能无法及时报告连接错误。你装了一台法拉利的引擎，结果跑起来跟三轮车似的。
玄学稳定性。 Nginx on Windows 的官方文档里至今仍列着“已知问题”——平时没事，流量一上来，什么诡异的超时都能遇到。根据社区讨论和实际测试，Windows 版 Nginx 的真实并发上限大约在 500 到 1500 连接，超过这个范围性能就会急剧下降。
那位前辈说“第一次见”，不是他见识少，是太离谱。世界还真是个草台班子。
第二件：connections 设了 20W，file-max 还是 1024
“贵司是否有专门的运维对 Linux 内核配置进行优化？我查看了部分机器的配置，nginx connections 设为 20W，但 Linux 的 file-max 还是默认值 1024。”
这条更狠，直接打在“根本没人管”的痛点上。
翻译一下就是：工程师在 Nginx 里写了 worker_connections 200000，觉得自己能扛 20 万并发。结果 Linux 系统冷冷地回了一句：“不，你最多开 1024 个文件。”
系统默认的 fs.file-max 通常是 1024（旧版）或者按内存自动算（新版），但无论如何，裸机默认值绝对到不了 20W。
Nginx 启动的时候一声不吭，你以为万事大吉。等流量一上来，日志里静悄悄出现 Too many open files，然后用户 502，老板拍桌子。
那位前辈说“查看了部分机器”——这个词最扎心。说明他随手查了几台，台台都是这样。
这不是某一个人的失误，是整个流程在裸奔。
一份只读脚本，帮你检查生产环境有没有裸奔
下面这份脚本是纯只读的，不会修改系统任何配置，放心在生产环境执行。它会扫描关键内核参数、limits.conf、常见服务进程的实际文件描述符限制，给出红黄绿状态。
将以下内容保存为 check_prod.sh，执行 sudo bash check_prod.sh：
[!quote]- 一键检测生产环境内核配置
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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
# ============================================================
# 文件名: check_production_sysctl.sh
# 用途: 检查生产环境内核参数是否符合推荐值（只读）
# 适用: Debian/Ubuntu/CentOS/RHEL
# ============================================================
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[0;33m'
BLUE='\033[0;34m'
NC='\033[0m'
# ---------- 推荐值定义（可根据实际内存调整） ----------
declare -A RECOMMENDED=(
["fs.file-max"]="2097152"
["fs.nr_open"]="1048576"
["kernel.pid_max"]="65536"
["net.core.somaxconn"]="65535"
["net.ipv4.tcp_max_syn_backlog"]="65535"
["net.core.netdev_max_backlog"]="65535"
["net.ipv4.tcp_syncookies"]="1"
["net.ipv4.tcp_tw_reuse"]="1"
["net.ipv4.tcp_fin_timeout"]="30"
["net.ipv4.ip_local_port_range"]="1024 65535"
["net.ipv4.tcp_max_tw_buckets"]="2000000"
["net.core.rmem_max"]="16777216"
["net.core.wmem_max"]="16777216"
["net.ipv4.tcp_rmem"]="4096 87380 16777216"
["net.ipv4.tcp_wmem"]="4096 65536 16777216"
["vm.swappiness"]="10"
["vm.overcommit_memory"]="1"
["net.netfilter.nf_conntrack_max"]="2097152"
)
echo -e "${BLUE}=============================================${NC}"
echo -e "${BLUE} 生产环境内核参数检查报告 (只读)${NC}"
echo -e "${BLUE} 时间: $(date)${NC}"
echo -e "${BLUE} 主机: $(hostname)${NC}"
echo -e "${BLUE}=============================================${NC}"
# ---------- 1. 内核参数检查 ----------
echo -e "\n${BLUE}>>> 1. 内核参数检查 (sysctl)${NC}"
echo -e "参数名 | 当前值 | 推荐值 | 状态"
echo -e "-------|--------|--------|------"
for param in "${!RECOMMENDED[@]}"; do
current=$(sysctl -n "$param" 2>/dev/null || echo "N/A")
rec="${RECOMMENDED[$param]}"
if [[ "$current" == "N/A" ]]; then
echo -e "$param | N/A | $rec | ${RED}NOT FOUND${NC}"
continue
fi
if [[ "$current" == "$rec" ]]; then
echo -e "$param | $current | $rec | ${GREEN}OK${NC}"
else
# 数值类型：当前值 >= 推荐值算通过
if [[ "$current" =~ ^[0-9]+$ ]] && [[ "$rec" =~ ^[0-9]+$ ]]; then
if [[ "$current" -ge "$rec" ]]; then
echo -e "$param | $current | $rec | ${GREEN}OK (>=推荐)${NC}"
else
echo -e "$param | $current | $rec | ${RED}WARN (偏小)${NC}"
fi
elif [[ "$current" =~ ^[0-9]+\ [0-9]+\ [0-9]+$ ]] && [[ "$rec" =~ ^[0-9]+\ [0-9]+\ [0-9]+$ ]]; then
cur_max=$(echo "$current" | awk '{print $3}')
rec_max=$(echo "$rec" | awk '{print $3}')
if [[ "$cur_max" -ge "$rec_max" ]]; then
echo -e "$param | $current | $rec | ${GREEN}OK${NC}"
else
echo -e "$param | $current | $rec | ${RED}WARN (最大值偏小)${NC}"
fi
else
echo -e "$param | $current | $rec | ${YELLOW}UNKNOWN${NC}"
fi
fi
done
# ---------- 2. limits.conf 检查 ----------
echo -e "\n${BLUE}>>> 2. /etc/security/limits.conf${NC}"
grep -E "^[^#]*nofile" /etc/security/limits.conf 2>/dev/null || echo "无有效配置"
soft_cnt=$(grep -E "^[^#]+\s+soft\s+nofile\s+65535" /etc/security/limits.conf 2>/dev/null | wc -l)
hard_cnt=$(grep -E "^[^#]+\s+hard\s+nofile\s+65535" /etc/security/limits.conf 2>/dev/null | wc -l)
if [[ "$soft_cnt" -gt 0 ]] && [[ "$hard_cnt" -gt 0 ]]; then
echo -e "${GREEN}✓ 已配置 nofile 65535${NC}"
else
echo -e "${RED}✗ 未正确配置 nofile 65535${NC}"
fi
# ---------- 3. 常见服务进程实际限制 ----------
echo -e "\n${BLUE}>>> 3. 常见服务进程实际限制${NC}"
for svc in nginx java redis-server mysqld postgres httpd; do
pids=$(pgrep -x "$svc" 2>/dev/null | head -2)
for pid in $pids; do
if [[ -f /proc/$pid/limits ]]; then
hard=$(grep "Max open files" /proc/$pid/limits | awk '{print $4}')
echo -e " $svc (PID $pid): 硬限制 = $hard $([ "$hard" -ge 65535 ] && echo "${GREEN}✓${NC}" || echo "${RED}✗ 建议>=65535${NC}")"
fi
done
done
# ---------- 4. systemd 服务检查 ----------
echo -e "\n${BLUE}>>> 4. systemd 服务 LimitNOFILE${NC}"
for unit in $(systemctl list-units --type=service --state=running 2>/dev/null | grep -E "nginx|java|redis|mysql|postgres" | awk '{print $1}'); do
nofile=$(systemctl show -p LimitNOFILE "$unit" 2>/dev/null | cut -d= -f2)
echo -e " $unit : LimitNOFILE = ${nofile:-未设置} $([ "${nofile:-0}" -ge 65535 ] 2>/dev/null && echo "${GREEN}✓${NC}" || echo "${RED}✗${NC}")"
done
echo -e "\n${BLUE}=============================================${NC}"
echo -e "${GREEN}检查完成。请关注标记为 WARN 或 ✗ 的项目。${NC}"
echo -e "${BLUE}=============================================${NC}"
最后说几句
那封投诉信里提到的两件事，单独拎出来看，每一件都不算“致命失误”——毕竟 Windows 跑 Nginx 也能转，file-max 没改也不一定会立刻崩。
但合在一起，暴露的是一个更根本的问题：这个团队的生产环境部署，没有标准，没有检查清单，没有敬畏心。
那位老前辈真正愤怒的，不是具体哪个选择做错了，而是这些错误“低级到只要有人在上线前随手查一下就能发现”。
系统能跑，不等于能活。能活过流量高峰，才叫生产环境。
生产环境不是玩具，是战场。
最近在公司内部翻到一封“技术投诉信”，字里行间的锐利让我出了一身冷汗。投诉对象是某部门上线的系统，投诉人显然是位见过世面的前辈。信里有两点特别扎眼，今天就借这两把“飞刀”，来聊聊生产环境部署的那些“不是玩具”的事。
投诉原文
(2)平台上线前部署代理操作系统为什么是 windows？我工作这么多年，多多少少接触了上百家公司，用 Linux 的至少 50 家，50 家里面你们是我见过第一家在 windows 上部署 nginx 的……
(3)贵司是否有专门的运维对 Linux 内核配置进行优化？我查看了部分机器的配置，nginx connections 设为 20W，但 Linux 的 file-max 还是默认值 1024。
两句话，两个巴掌，打在了两个不同的“常识”上。我们来一个个拆。
第一巴掌：Nginx + Windows，是什么神仙组合？
Nginx 诞生于 Linux 世界，它的 epoll（Linux） 和 kqueue（BSD/macOS） 事件模型是高并发的基石。Windows 上虽然也有 IOCP，但 Nginx 官方对 Windows 的支持定位是 “开发测试”，生产环境强烈推荐 Linux。
那为什么有些团队会选 Windows？
- 历史包袱：早期业务跑在 .NET/IIS 上，懒得迁；
- 运维技能树单一：团队只熟 Windows，没 Linux 人手；
- 反正能跑：启动后没报错，就以为万事大吉。
但代价是什么？
- 性能折损：Windows 上的 Nginx 用 select/poll 模型，单进程并发上限被锁死在 1024 级别；
- 稳定性玄学：Nginx on Windows 的 release notes 常年写着 “known issues with large number of connections”；
- 生态割裂：要调优内核参数？Windows 的注册表调优和 Linux 的
/etc/sysctl.conf完全两个宇宙。
第二巴掌：connections=20W，file-max=1024，这比“渣男”还渣
这巴掌更狠，直接打在了内核参数没人管的痛点上。
Linux 系统默认的 fs.file-max 通常是 1024（旧版）或按内存计算（新版），但无论如何，裸机默认值绝不会是 20W。而 Nginx 配置里设置了 worker_connections 200000，意味着每个 worker 进程希望打开 20 万个文件描述符。
结果呢？系统说：不，你最多只能开 1024 个。 Nginx 启动时不会报错，但一旦流量上来，日志里就会 quietly 出现 Too many open files，然后连接被拒绝，用户 502，老板拍桌。
这不是技术问题，这是运维基本素养的缺失，更可怕的是，这类疏忽往往不是孤例——投诉人“查看了部分机器”就发现，说明批量部署脚本里根本没有内核参数检查步骤。
用一份检查脚本，检查你的生产环境是否“裸奔”
下面这份脚本是纯只读的检查脚本，不会修改系统任何配置，可以放心在生产环境执行。它会扫描所有关键内核参数、limits.conf 配置、正在运行的常见服务进程的实际文件描述符限制，并给出红黄绿状态评估。
将以下内容保存为 check_prod.sh，然后执行 sudo bash check_prod.sh：
1 |
|
系统不是能用就可以，生产环境不是玩具
投诉信里的那位老哥，真正愤怒的，不是“Windows 跑 Nginx”这个选择本身——毕竟每个团队有自己的历史包袱。他愤怒的是：你们在选择了一个非常规方案后，没有给出任何额外的论证、测试或补偿措施。
他愤怒的，也不是“file-max 没改”这个具体失误——毕竟谁都会忘。他愤怒的是：这个失误如此低级，以至于只要有人在上线前执行一次 sysctl -a | grep file-max 就能发现，但显然没有人做过。
这两件事合并起来，暴露了一个更严重的问题：这个团队的生产环境部署，没有标准，没有检查清单，没有敬畏心。
我们做技术的，往往迷恋代码里的优雅设计，却忽略了下线后的运行环境。但真正决定系统上限的，从来不是那几行业务逻辑，而是操作系统配置、网络栈参数、文件句柄限制这些看不见的基石。
一块基石歪了，整个大厦就摇摇欲坠。而生产环境里，没有重启试试这种后悔药。生产环境不是玩具，是战场。 而我们应该做个合格的士兵，不是马马虎虎的炮灰。
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 暮色之狐！
wechat
alipay
相关推荐
2026-08-05
Docker日志太多撑爆硬盘？一次搞定日志轮转与清理
运维过Docker容器的朋友，大概率都经历过这样的惊魂时刻：突然收到磁盘告警，df -h一看，根目录使用率100%。顺着路径查下去，发现/var/lib/docker/containers/下躺着好几个几十GB的日志文件。 没错，Docker默认的json-file日志驱动不会自动轮转。容器里输出的每一条日志都会被原封不动地记录下来，日积月累，直到撑爆你的硬盘。 今天这篇文章，就带你彻底解决这个问题——包含全局配置、单容器配置，以及旧日志的清理方案。 全局配置（推荐生产环境兜底）修改Docker守护进程的配置文件/etc/docker/daemon.json（如果文件不存在，新建即可）： 12345678{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3", "compress":...
2026-08-04
手把手教你给Debian服务器换国内镜像源，速度瞬间起飞！
由于众所周知的原因，在国内使用Debian服务器，那么更换国内镜像源这件事几乎可以算是装机后的必备操作，虽然这个操作不常做，但却是运维的必备技能。 国内有一大批高速、稳定的镜像站（阿里云、清华、中科大……），换上之后，速度立竿见影，体验瞬间从“煎熬”变成“丝滑”。 今天我们就用最直接的方式，一步步和你一起完成配置。 第一步：查清你的Debian版本代号登录服务器，执行下面这条命令： 1lsb_release -c 你会看到一个代号，比如： bookworm → Debian 12 bullseye → Debian 11 buster → Debian 10请一定记住这个代号，后面配置全靠它。 第二步：确认你的配置文件格式（关键！）Debian 12开始引入了一种新格式，配置文件位置变了。我们分两种情况，对号入座就行。 📁 情况A：传统格式（适用于Debian 11及更早，或部分Debian 12）配置文件是 /etc/apt/sources.list ① 先备份（防手误） 1sudo cp /etc/apt/sources.list /etc/apt/sources.l...
2025-11-18
配置nginx实现https访问
安装nginx在官网下载和系统匹配的nginx，解压即可 安装OpenSSL若网站有https的证书跳过2、3、4步即可，若没有证书则需要自己生成 由于代理https需要使用证书，这里我们使用OpenSSL生成自签名的证书，可以下载与系统相匹配的OpenSSL程序进行安装，安装过程一直下一步即可，下载地址 配置环境变量 新增环境变量 OPENSSL_HOME，变量值为 D:\OpenSSL-Win64，指向OpenSSL的安装路径 新增环境变量 OPENSSL_CONF，变量值为 D:\OpenSSL-Win64\bin\openssl.cfg，指向openssl.cfg文件目录 在环境变量path的末尾添加 %OPENSSL_HOME%\bin 生成证书在nginx安装目录创建 ssl文件夹，用于存放证书，如我的是 F:\nginx-1.16.1\ssl，以管理员权限运行cmd并进入创建的ssl目录 创建私钥在命令行中执行命令 openssl genrsa -des3 -out demo.key 1024 ，demo是私钥文件名，可以自定义，此处需要输入和验证密码，输入的密码...
2025-11-20
Linux防火墙命令
linux系统常用的防火墙分别是iptables和firewall防火墙，记录一下常用的命令 firewall防火墙12345678910111213141516171819202122232425#查看firewall服务状态systemctl status firewalld#查看firewall的状态firewall-cmd --state# 开启service firewalld start# 重启service firewalld restart# 关闭service firewalld stop#查看防火墙规则firewall-cmd --list-all # 查询端口是否开放firewall-cmd --query-port=8080/tcp# 开放80端口firewall-cmd --permanent --add-port=80/tcp# 移除端口firewall-cmd --permanent --remove-port=8080/tcp#重启防火墙(修改配置后要重启防火墙)firewall-cmd --reload 参数解释firwall-cmd：是Lin...
2026-07-28
Docker部署Keycloak：企业级身份认证平台搭建
为什么选择 Keycloak？ 特性 Keycloak 开箱即用 OAuth2/OIDC/SAML 全支持 单点登录 原生支持 SSO 社交登录 微信/GitHub/Google 等开箱即用 用户管理 完整的管理控制台 企业认可度 Red Hat 出品，大量企业使用 本文聚焦 Docker 环境下的 Keycloak 部署与日常运维。 一、快速部署1. 准备数据库Keycloak支持多种数据库，下面以MySQL数据库举例 123456789101112131415-- 1. 创建数据库（指定字符集为 utf8mb4，以支持 Emoji 等特殊字符）CREATE DATABASE IF NOT EXISTS keycloakCHARACTER SET utf8mb4COLLATE utf8mb4_unicode_ci;-- 2. 创建用户（如果用户已存在，会先删除再重建，请确保数据安全）DROP USER IF EXISTS 'keycloak'@'%';CREATE US...
2026-07-31
只有1个公网IP怎么玩？OpenVPN跨网络组网实战指南
很多朋友会遇到这样的情况：手上有三台机器——机器A、机器B、机器C，它们各自处于不同的网络中，只有机器A拥有公网IP，机器B和机器C要么在NAT后面，要么在完全隔离的内网里，外面根本访问不到。 这时候问题来了：怎么让这三台机器像在同一个局域网里一样互相通信？ 用OpenVPN就能搞定！把有公网IP的机器A作为VPN服务端，机器B和机器C作为客户端拨入，三台机器就在同一个虚拟内网里了 网络拓扑图先看一下整体架构： 核心思路很简单：机器B和机器C主动向机器A发起VPN连接，建立加密隧道后，三台机器就在同一个虚拟子网（如10.8.0.0/24）里了。 完整配置步骤第一步：机器A（服务端）配置在机器A上编辑OpenVPN服务端配置文件（通常是/etc/openvpn/server.conf）： 12# 开启客户端之间互访client-to-client 如果机器B和机器C各自还有自己的内网子网需要互通（比如机器B后面还连着一个192.168.1.0/24的局域网），还需要在服务端配置中添加路由推送： 123# 推送路由给所有客户端push "route 192.168.1.0...
