旧笔记勘误
本专题从 notebook-gitee 的面试、Django/uWSGI 实验和 Obsidian 的系统性能笔记中提炼。以下内容不再按原文迁移，而是保留问题与修正结论。
概念与架构
| 旧笔记说法 | 问题 | 修正结论 |
|---|---|---|
| Forward Proxy 与 Reverse Proxy 的定义 | 两个定义写反 | Forward Proxy 代表 Client；Reverse Proxy 代表 Server |
| Proxy 与其代表的一方必须在同一个 LAN | 把常见拓扑写成协议条件 | 是否同网段不决定代理类型，关键是代理代表哪一方 |
| Master 每收到一个 Client 就创建一个 Worker，断开后 Worker 退出 | 错误描述成 Process-per-connection | Master 管理长期 Worker；Worker 通过 Event Loop 同时处理大量 Connection |
| epoll 是一个“排队解决”的队列 | 过度简化 | epoll 是 Linux I/O Event Notification Interface，Application 仍需处理 Readiness Event 和非阻塞 I/O |
| Nginx 支持 HTTP、HTTPS、SMTP、POP3、IMAP，所以默认都能代理 | 忽略 Module 和配置边界 | Mail Proxy 依赖 Mail Module；HTTP 与 Stream/Mail 使用不同 Module 和配置 Context |
负载均衡与会话
| 旧笔记说法 | 问题 | 修正结论 |
|---|---|---|
ip_hash 解决 Session Sharing | Sticky Routing 不等于共享 | ip_hash 只是尽量把同一 IP 路由到相同 Server；NAT、Proxy、IPv6、节点故障都会影响结果 |
| Backend Down 后会自动剔除 | 没有说明 Open Source Nginx 的被动检查语义 | max_fails、fail_timeout 基于真实请求失败临时标记；主动 Health Check 能力和版本/产品有关 |
| Weight 是“访问概率” | 容易被理解成严格随机概率 | Weight 参与 Balancing Decision，短窗口分布和实际完成量不保证严格比例 |
| Retry 可以直接提高可靠性 | 未考虑重复副作用 | 非幂等请求自动重试可能重复执行，必须限制条件并设计 Idempotency |
性能参数
| 旧笔记说法 | 问题 | 修正结论 |
|---|---|---|
worker_processes auto 一定等于 CPU Core 数且最优 | Container CPU Quota、NUMA 和 Workload 会影响选择 | auto 是合理 Baseline，仍需结合 CPU Affinity、Quota 和压测验证 |
worker_connections × worker_processes 就是最大并发 | Reverse Proxy 还占用 Upstream Connection 和其他 FD | 它只是 Connection Capacity 的一个上限因素 |
| 固定 Buffer、Timeout、Gzip Level 是通用最佳实践 | 参数来自特定环境经验 | 根据 Header、Body、Latency、CPU 和 SLO 分布压测 |
sendfile 表示文件始终只在 Kernel Space 中传输 | 忽略 TLS、OS、Filesystem 等实现差异 | 它启用高效文件传输路径，具体 Copy Path 由环境决定 |
| Gzip 应包含 WebP、Icon 等大量二进制类型 | 多数已压缩格式收益很低 | 优先压缩 Text、CSS、JavaScript、JSON、XML、SVG，并测量 CPU/带宽收益 |
$request_time 等于 Application 执行时间 | 包含 Client/Nginx/Upstream 多段时间 | 结合 $upstream_connect_time、$upstream_header_time 和 $upstream_response_time 分析 |
缓存与安全
| 旧笔记说法 | 问题 | 修正结论 |
|---|---|---|
no-cache 表示完全不缓存 | 与 HTTP Cache 语义不符 | 可以存储，但复用前必须 Revalidate；no-store 才是不应存储 |
| HTML “绝对不能强缓存” | 结论依赖发布方式 | 常见 SPA Entry 应短缓存或验证；若 URL Versioned 或有原子发布策略可以另行设计 |
| 配置一组固定 Security Header 就安全 | Header 需要与应用资源和 Domain 策略配合 | CSP、HSTS 等必须逐项设计和验证，不能代替 Authentication、Authorization 和 Patch |
| IP Rate Limit 可以阻挡恶意流量 | NAT、Proxy、Botnet 会削弱 IP 语义 | 恢复可信 Client IP，并结合 User、Tenant、Token 和业务资源限流 |
安装与运维
| 旧笔记说法 | 问题 | 修正结论 |
|---|---|---|
使用 CentOS 7 和 nginx-release-centos-7-0.el7.ngx.noarch.rpm | CentOS 7 已结束常规生命周期，命令绑定旧环境 | 使用当前受支持 OS 的官方 Package Repository 或 Distribution Package |
| 为了部署关闭 SELinux、防火墙 | 扩大攻击面，也掩盖策略配置问题 | 保持安全机制启用，配置所需 Port、Label 和 Boolean |
使用 netstat 作为默认排障命令 | 工具仍可能存在，但现代 Linux 通常使用 iproute2 | 使用 ss -lntp，必要时配合 lsof、tcpdump |
修改配置后直接 nginx -s reload | 缺少 Syntax 和资源检查 | 先 nginx -t，再 Reload，并做 Endpoint Smoke Test |
tail -f 和 `ps -ef | grep nginx` 足以定位问题 | 只能确认局部现象 |
保留下来的有效内容
以下思路经过修正后仍保留在专题中：
- Master/Worker 与 Event-driven Architecture；
- Reverse Proxy、Upstream、Round Robin、Least Connections 和 Weight；
- Static Asset Cache、SPA Fallback、Gzip；
- Django/uWSGI 通过
uwsgi_pass接入； $request_time与 Upstream Timing 日志；- Syntax Check、Graceful Reload、Error Log 和 Status Code 排查。