张鹏的博客

服务器要长期对外提供服务，IP 就不能漂：DHCP 租约一续，地址一变，远程访问、DNS 解析、防火墙白名单跟着全断。这篇把 RHEL 9 系（Rocky Linux 9）上配静态 IP 的完整做法记录下来——单网卡怎么配、多网卡时默认出口选谁、特定网段的流量怎么指到指定网卡，以及两处最容易翻车的地方。全部步骤在 Rocky Linux 9.3 容器里实跑过，文末附 CentOS 7 的 ifcfg 时代差异对照。 核心机制一句话RHEL 9 起网络由 NetworkManager 统一管理：一条 nmcli connection 命令对应一份落盘在 /etc/NetworkManager/system-connections/*.nmconnection 的 keyfile 配置，nmcli con up 让它生效；多网卡分流靠连接配置里的 ipv4.routes（CentOS 7 时代是 route-ethN 文件）。运行时验证始终是 ip addr 加 ip route show。 实验环境 操作系统：Rocky Linux 9.3 容器（NetworkManager 1....

高负载服务器的磁盘 IO 打满时，除了换硬件，还有一个内核参数值得试：I/O 请求队列长度 nr_requests。它决定每个块设备能同时排队多少个请求，调大之后多任务场景下磁盘调度余地更大，延迟往往能降下来。这篇记录在 Rocky 9 上查看和调整它的方法，查看、调整、验证动作均在 Rocky 9.3 容器实测，实测同时暴露了一个”写不进去”的坑，一并给出。 实验环境 Rocky Linux 9.3 一次性容器（docker run --privileged，读写 /sys 需要）； 实测对象：容器可见的 vda（virtio 虚拟盘，默认 256）与 loop 盘（默认 128）； iostat 来自 sysstat 12.5.4； 物理机上 SATA/SAS 盘同样走 /sys 这套接口，操作方式一致。 请求队列长度影响什么Linux 里每个磁盘设备都有自己的 I/O 请求队列，队列长度就是设备可以缓存的请求数量。队列更长，内核就能把更多请求攒在一起做调度和合并，在高负载、多任务的环境下效果明显；代价是管理这些请求需要消耗...

MySQL 崩溃、实例起不来，手上又没有逻辑备份时，数据目录里的文件本身就是最后的救命稻草：.frm 存着表结构，.ibd 存着表数据和索引（InnoDB 独立表空间模式下每张表一个）。只要这两个文件还在，就能把它们挂回一个新实例里把数据捞出来。这篇用一个 mysql:8.0 容器把整条恢复链路实跑一遍——能恢复什么、顺序错一步会发生什么、5.x 和 8.0 差在哪。 实验环境与版本边界先说清楚环境，因为这套方法对版本高度敏感： 实测环境：Docker 容器 mysql:8.0.46（2026-09 实跑，下文所有输出都来自这次实验）。 MySQL 5.x：每张表一对 .frm（表结构）+ .ibd（数据与索引）。 MySQL 8.0 起：.frm 被移除，表结构存进数据字典（mysql.ibd），每张表的数据目录里只剩 .ibd。 前提：手上留着出事前的 .ibd 文件（最好连 .frm 一起），且目标实例与源实例大版本一致——版本不一致时表空间格式可能不兼容，IMPORT 直接失败。 一个版本判断原则：5.x 的恢复素材是”一对文件”，8.0 的恢复素材是”一个 .ibd...

想知道网站当前谁在访问、流量什么模式、有没有异常请求，GoAccess 可以直接在日志上给出答案。它是开源的 Web 日志分析工具：不依赖数据库、不往服务器上装 agent，一条命令读 Nginx/Apache 的访问日志就能出统计——终端界面、HTML 报告、JSON 都支持，--real-time-html 模式还能让报告跟着日志实时刷新。这篇按使用场景整理它的用法，实测环境为 debian:12 容器内的 GoAccess 1.7（Rocky 9 EPEL 上的 1.11 顺带验证了安装），日志示例为自造的 5 条 combined 格式测试日志。 安装大多数发行版的仓库里都有。Debian/Ubuntu： 1sudo apt-get install -y goaccess CentOS/RHEL/Rocky 要先启用 EPEL 仓库（Rocky 9 实测 dnf 版命令，装到 GoAccess 1.11）： 12sudo dnf install -y epel-releasesudo dnf install -y goaccess...

排查 Nginx 性能问题或异常退出，第一步通常是搞清楚它内部的进程都在干什么。把 Nginx 的进程结构想成一家餐厅就好懂了：经理（master）不炒菜，负责排班、验菜单、招人辞人；后厨多位厨师（worker）各守一灶，客人点的每一道菜都出自他们之手；还有两位兼职的仓储员，只在启用缓存时才出现。Nginx 的正式定义是：一个 master 进程加一组 worker 进程的多进程模型，master 管理与调度，worker 承接全部客户端请求。 三类进程，三种职责master 进程是唯一的管理者。 它负责读取和验证配置、绑定端口、拉起并监控 worker、处理信号——日常操作里的 nginx -s reload 和 nginx -s stop，接信号的始终是 master。它自己不碰任何客户端请求，只保证”干活的人”在岗。 worker 进程是全部请求的承接者。 每个 worker 独立跑一个事件循环，管理成百上千的连接；worker 数量默认与 CPU 核心数对齐，让每个核心跑一个 worker，互不抢占。实际处理请求、代理转发、返回响应的都是 worker。事件循环用的多路复...

Nginx 的配置文件层级深、块多，一个站点拆出几十行 location 很常见。编辑器没有语法高亮时，引号没闭合、大括号不配对这类低级错误很难一眼看出来，nginx -t 报错还得回头逐行找。这篇按编辑器给出开启高亮的具体做法：VS Code 走扩展市场一键装；Vim 先做 30 秒识别体检——近年版本的 Vim 已把 Nginx 识别收进自带运行时，开箱即用，体检不过关再从 Nginx 源码包拷官方语法文件（两步都有完整实测）。 按你用的编辑器跳转： 用 VS Code → 看第 1 节，两分钟搞定； 用 Vim → 看第 2 节，先体检再决定装不装，附对照组实测和两个真实的坑。 VS Code：装一个扩展VS Code 内置的语言支持里没有 Nginx 配置，需要装扩展补上。打开扩展市场（Ctrl+Shift+X），搜索 nginx.conf，选择安装量高的那个装上即可。挑扩展时看两点：一是更新时间，Nginx 指令逐年增加（如 grpc_pass、http2 相关），久不更新的扩展会把这些新指令标成”未知”；二是安装量，百万级安装的扩展基本不存在乱标关键字的问题。 装...

站点上了 HTTPS 之后，仍会有人拿 IP 直接扫 443 端口——这类请求的 Host 不是你的域名，应该在握手阶段就拒掉。这篇记录 Nginx 上配 HTTPS 并禁止 IP 访问的完整过程，包括一个实测踩到的配置坑：用 if 加 && 判断 Host 的写法在 Nginx 里根本无法通过语法检查，正确姿势是 default_server 兜底拒绝。全文在 nginx:alpine 容器（nginx/1.31.5，自签证书）里实跑验证，文末附 CentOS 7 老版本 Nginx 的差异。 核心机制一句话HTTPS 由证书加 listen 443 ssl 决定；拒绝 IP 访问的关键在于：非目标域名的 TLS 请求会落进 SNI 匹配失败的 default_server 块，把这块配置成直接拒绝握手，IP 直连就进不了业务站点。 准备工作与证书申请开始前确认两件事：服务器上已装好 Nginx；域名有一张有效的 SSL/TLS 证书。证书从 Let’s Encrypt 免费申请即可，配套的 Certbot 能自动完成申请和 Nginx 配置...

Nginx 后面挂的应用一旦响应变慢，超时问题就来了：用户侧看到的是页面转圈后一个 504，日志里是一行 upstream timed out。但 Nginx 里名字带 timeout 的指令有十几个，连接超时到底归谁管、该调哪一个，不把参数分工搞清楚，调参就是碰运气。这篇把 keepalive_timeout 和 proxy_* 三个超时参数放进一次请求的完整链路里讲清楚，给出一套面向长耗时应用的基线配置，并用容器实测展示读超时触发 504 的完整现场。 实验环境结论要能复现，先交代条件： nginx/1.31.5（docker 镜像 nginx:alpine，一次性容器，用完即删）； 同一容器内用 nc 起一个”只收请求、不回响应”的静默后端，模拟慢应用； 每轮改动配置后 nginx -s reload，用 curl 验证状态码和耗时。 四个参数各管一段核心机制一句话：一次代理请求横跨”客户端↔Nginx↔后端”两段链路，每个超时参数只守其中一段，先分清链路再调参。 参数 守护的链路段 触发后的表现 keepalive_timeout 客户端 ↔ N...

负载均衡就是把流量分配到多台服务器上，让资源利用更充分、吞吐量更大，也避免单台机器被打挂。Nginx 两种都能做：七层（HTTP）开箱即用，四层（TCP/UDP）靠 stream 模块。这篇在 nginx:1.28 容器里把两种负载均衡同时跑起来——同一组后端，两个入口，看它们的分发行为和能力边界差在哪。 实验环境 Docker 容器 nginx:1.28-alpine（nginx/1.28.3，nginx -V 确认编译了 --with-stream，2026-09 实测）。 两个”后端”：同容器内 8081 端口返回 APP-ONE，8082 端口返回 APP-TWO——响应体带身份，分发到谁一目了然。 演示配置用 worker_processes 1：多 worker 下每个进程有独立的轮询游标，快速连发时流量会集中到各 worker 的首个后端，单 worker 让轮询效果最直观。 七层负载均衡：能看内容，才能按内容路由http 块里的标准三件套——upstream 后端组、入口 server、代理转发： 123456789101112131415h...

恶意用户或自动化脚本高频请求网站，轻则拖慢体验，重则耗尽服务器资源。Nginx 的 limit_req 可以在代理层直接控制客户端的请求速率，把滥用流量挡在后端之前。这篇在 nginx:1.28 容器里用三组对照实验把 rate、burst、nodelay 三个参数的行为实测一遍——每种组合被拒绝多少、延迟多少，数据说话。 使用场景三类典型需求：缓解 DDoS，限制单 IP 速率让攻击流量不再直接打穿后端；限制 API 用量，按客户端控制每秒请求数，保护后端不被滥用；保护登录注册入口，抑制暴力破解和批量注册脚本。 配置示例123456789101112http { limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s; server { listen 80; location / { limit_req zone=mylimit burst=5 nodelay; proxy_pass http://...