Web 服务器

你有没有想过：一台机器只在 443 端口上监听，浏览器、手机 App、搜索引擎和监控探针却能同时访问它；同一个公网 IP 上还能放十几个域名，每个域名展示的内容都不一样。端口明明只有一个，服务器究竟怎么知道“这条请求该交给谁”？

答案不是“服务器把一个端口切成了很多份”。真正发生的是：监听端口只负责迎接新连接，操作系统会为每条已建立连接创建独立的套接字；Web 服务器再从连接里解析 HTTP 请求，根据协议、主机名、路径和方法选择处理方式。静态文件可能直接从磁盘返回，API 可能被转给应用进程，另一些请求则会被拒绝、限速或记录下来。

这条链路看上去只是“收请求、发响应”，但生产环境里每个环节都在做取舍：多留一些连接能减少握手，却会多占文件描述符和内存；开启响应缓冲能保护上游应用，却可能拖慢流式输出；把超时设短能更快回收资源，却可能误伤慢网络和大文件上传。理解 Web 服务器，关键不是背配置项，而是知道每个开关在保护什么资源，又会把代价转移到哪里。

一个端口为什么能接住很多连接

先把最容易混在一起的三个词拆开：端口、连接、请求。

端口是服务器进程在本机上的监听入口。程序先创建监听套接字，把它绑定到某个 IP 和端口，再开始监听。客户端完成连接建立后，服务器调用 accept，操作系统会返回一个新的“已连接套接字”。原来的监听套接字仍然留在端口上，继续接待下一位客户端。

所以，成千上万条连接并没有挤进同一个不可区分的管道。每条 TCP 连接都可以由源 IP、源端口、目标 IP、目标端口这组信息区分。即使所有客户端访问的目标都是 203.0.113.10:443，它们的源地址和源端口也不同，操作系统知道每个数据包属于哪条连接。

连接不等于请求

浏览器建立一条连接，不代表它只能发送一次请求。HTTP/1.1 常用持久连接，一条连接可以先后承载多个请求；HTTP/2 还能在一条连接上并发传输多个请求流。反过来，一个网页也可能同时使用多条连接加载不同资源。

因此下面几个数字不是一回事：

• 连接数表示当前有多少网络会话占着套接字。
• 活跃请求数表示此刻有多少请求正在解析、等待上游或发送响应。
• 每秒请求数表示一段时间内完成了多少请求。
• 业务并发数还可能包含已进入队列、数据库或任务系统的工作。

如果你只看“每秒请求数很高”，不能直接得出“连接数一定很高”；长连接、长轮询和流式响应又可能呈现相反情况：请求到达频率不高，连接却长期占用。

accept 前后发生了什么

新连接不会直接跳进应用代码。它先经过网卡、内核网络栈和监听队列。服务器还没来得及接收时，已完成握手的连接会暂存在队列里；服务器从队列中取走一个连接后，才获得可读写的文件描述符。

这解释了一个常见现象：CPU 看起来并不高，用户却连接失败。问题可能不在业务代码，而在监听队列已经溢出、文件描述符耗尽、网卡或防火墙丢包，或者工作进程根本来不及调用 accept。把 backlog 调大只能增加短时缓冲，无法修复一个长期处理不过来的系统。

服务器怎样同时照看成千请求

如果每来一个请求都临时创建进程，隔离性会很直观，但进程创建和内存开销很快就会变重；如果所有工作都塞进一条线程，某个慢操作又可能拖住其他请求。现代 Web 服务器很少只用一种模型，而是组合进程、线程、事件通知和任务队列。

多进程：用边界换资源

多进程模型把工作分散到多个地址空间。一个子进程崩溃时，其他进程通常还能继续服务；不同进程也可以使用不同权限。代价是每个进程都有自己的内存和运行时，进程间共享状态更麻烦。

“多进程”也不一定表示每个请求都新建一个进程。常见做法是预先创建进程池，让已有子进程接收请求。Apache 的 prefork 模式就是非线程化的预派生模型，适合需要兼容非线程安全组件的场景，但并发上限通常会直接推高进程数量和内存消耗。

多线程：共享方便，协调更难

线程共享进程内存，建立和切换通常比进程轻。线程池可以预先准备固定数量的工作线程，请求到来后从池中取一个执行，避免反复创建和销毁线程。Apache 的 worker 和 event 模式会组合多进程与多线程；event 还会减少持久连接空闲等待对工作线程的占用。

共享内存带来效率，也带来锁、竞争、死锁和线程安全问题。线程数继续增加时，栈内存和上下文切换会增长。线程池太小，请求在队列里等；线程池太大，CPU 可能忙着切换而不是做业务。

事件驱动：只处理已经就绪的连接

事件驱动模型不会给每条空闲连接配一条专属线程。服务器把大量套接字注册给操作系统；当某个套接字可以读取、可以写入或出现错误时，操作系统才通知事件循环。Linux 上常见 epoll，BSD 系统常见 kqueue，Windows 则有自己的完成通知机制。

Nginx 通常由主进程读取配置、管理工作进程，工作进程通过事件机制处理大量连接。少量进程就能照看很多处于等待状态的套接字，这是它适合做静态文件服务器和反向代理的重要原因。

但“事件驱动”不等于“任何工作都不会阻塞”。如果事件循环里直接执行大规模压缩、复杂正则、同步磁盘读取或长时间计算，这段时间其他就绪事件也得等。Node.js 的网络 I/O 由事件循环协调，部分文件系统、密码学和压缩任务会交给工作线程池；真正耗 CPU 的 JavaScript 仍可能堵住事件循环。要利用多核，往往还需要多进程、工作线程或把计算交给独立服务。

没有一种模型永远更快

I/O 等待多、单次回调短的工作很适合事件驱动；大量阻塞式库更容易放在线程池或独立进程里；不可信插件和兼容性要求高的模块可能值得用进程隔离。最终选择还受运行时、操作系统和团队排障能力影响。

真正应该问的是：请求大部分时间在等网络、等磁盘、等数据库，还是在消耗 CPU？阻塞发生时会拖住一个线程、一个进程，还是整个事件循环？失败后能否只重启一小块？这些问题比“哪种架构最先进”有用得多。

一次请求从 accept 走到响应

我们沿着一次 HTTPS 请求走一遍。假设目标域名是 api.example.test，路径是 /orders/42，DNS 已经把域名解析到服务器地址。

连接进入内核与工作进程

数据包先到操作系统网络栈。TCP 握手完成后，连接进入监听队列；某个工作进程调用 accept 取得新的套接字，并把它设为非阻塞。事件循环开始关注这个文件描述符后，不需要一直轮询读取；等数据到达，操作系统会告诉它“现在可读”。

服务器也可能在这一层就失败：监听队列满、进程文件描述符达到上限、全局文件表不足、内存无法分配，或者访问控制规则拒绝连接。此时应用日志甚至看不到请求，因为请求还没到 HTTP 层。

TLS 先于 HTTP

访问 HTTPS 时，服务器首先处理 TLS 握手。客户端会带上支持的协议版本、加密参数和通常包含目标域名的 SNI。服务器据此选择证书和 TLS 配置，双方建立加密会话后，HTTP 请求才在加密通道里传输。

这条顺序很关键：Host 是 HTTP 请求字段，TLS 选证书时还没有读到它。多个 HTTPS 站点共享同一 IP 和 443 端口，主要依靠 SNI 在握手阶段选择证书，之后再靠 HTTP 的主机信息选择站点配置。

解析请求必须有边界

服务器读取请求行、头字段和可能存在的请求体，再检查格式、长度和超时。这里不能“能收多少就收多少”。如果请求头数量无限、单个字段无限长、请求体没有上限，少量慢客户端就可能长期占住内存和连接。

解析完成后，服务器得到方法、目标路径、主机信息、内容类型、请求体长度等数据。HTTP/1.1 通常使用 Host，HTTP/2 和 HTTP/3 常使用 :authority 表达目标主机。代理转发时必须明确这些值来自谁、是否经过验证，不能把任意客户端输入直接当成内部路由或跳转地址。

先选站点，再选路径

服务器通常先按接收连接的 IP 和端口缩小配置范围，再按 SNI 或 HTTP 主机名选择虚拟主机，最后在站点内部匹配路径规则。例如：

• /assets/ 映射到静态目录；
• /api/ 转发到应用服务；
• /healthz 由服务器直接返回健康状态；
• 未知路径返回 404；
• 未知主机进入一个明确的默认站点并被拒绝。

路径匹配并不总是“配置从上到下，碰到第一个就停”。不同服务器对精确匹配、前缀匹配和正则匹配有各自优先级。改配置前要先弄清当前实现，否则一条看似更具体的规则可能根本没有机会执行。

内容生成与响应发送

静态资源可以由 Web 服务器打开文件、确定媒体类型、处理缓存条件和范围请求，再把内容送入套接字。动态请求则可能被代理给应用服务器，等待应用返回状态码、响应头和响应体。

响应不一定一次写完。客户端接收慢时，套接字发送缓冲区会填满，服务器需要等下次“可写”事件；代理服务器也可能先把上游响应放进内存或临时文件，避免一个慢客户端长期拖住上游连接。最后，服务器记录访问日志，决定复用连接还是关闭连接。

错误码透露了故障位置

状态码不是绝对证据，却能帮助缩小范围。400 常见于请求格式或主机信息不合法，404 表示选中的处理规则没有找到资源，413 常见于请求体超过限制，429 表示触发速率策略。502 往往表示代理拿不到有效上游响应，504 则常见于等待上游超时。

不过，浏览器看到超时而服务器访问日志没有记录时，要把视线往前移：DNS、网络、TLS、监听队列和连接上限都可能在 HTTP 日志之前失败。

路由、静态文件与反向代理

对服务器来说，路径不是“业务含义”，而是匹配输入。它需要把 /logo.svg 变成一个文件，把 /api/orders 变成一个上游请求，或者明确拒绝它。边界模糊时，最容易出现绕过、文件泄露和代理错路由。

静态文件不是简单的读文件

提供静态文件至少要处理这些问题：

• URI 如何映射到文件系统路径，规范化后是否还在允许的根目录内；
• 目录是否允许列出，默认索引文件是什么；
• 符号链接会不会跨出内容目录；
• 文件的 Content-Type 是否正确；
• 是否支持 ETag、修改时间、条件请求和范围请求；
• 哪些文件可以长期缓存，哪些 HTML 必须及时更新；
• 进程用户是否只有读取权限，而没有修改应用和密钥的权限。

sendfile 可以让内核在文件描述符之间传输数据，减少“读进用户空间再写回内核”的拷贝和系统调用开销。它适合普通静态文件，但不是所有链路都能直接使用：实时压缩、应用层改写、某些 TLS 实现和平台差异都可能改变实际数据路径。是否获益要看系统调用、CPU 和吞吐指标，而不是看到开关就默认打开。

静态资源缓存也有代价。带内容哈希的 JS、CSS、图片适合长缓存；入口 HTML 如果同样缓存一年，发布后用户可能拿着旧页面去请求已经不存在的新旧混合资源。缓存策略要和文件命名及发布流程一起设计。

反向代理是在划分职责

Web 服务器常把连接管理、TLS、静态资源、压缩、限流和基础访问控制挡在前面，把业务请求转给应用。这样做能让应用更专注于业务，也能在多个应用实例之间分配流量。

但代理多一层，就多一组边界：客户端地址可能变成代理地址，协议可能从 HTTPS 变成内网 HTTP，原始主机名可能被替换。应用如果需要这些信息，应由受信代理写入约定字段，并且只在请求确实来自受信代理时读取。否则攻击者可以自己伪造“原始客户端 IP”或“原始协议”。

下面是一段教学用 Nginx 配置，重点是展示职责划分，不是可以原样复制到任何生产环境的万能模板：

upstream backend_app {
    server 127.0.0.1:3000;
    keepalive 32;
}
 
server {
    listen 443 ssl;
    http2 on;
    server_name api.example.test;
 
    ssl_certificate     /etc/nginx/tls/api.example.test/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/api.example.test/private.key;
 
    location /assets/ {
        alias /srv/example-assets/;
        try_files $uri =404;
        expires 7d;

这里还有一个容易踩的坑：proxy_pass 是否带 URI、location 是否以斜杠结尾，会影响上游收到的路径。配置看起来只差一个 /，结果可能从 /api/orders 变成 /orders，也可能保留原路径。修改后要用真实路径组合做测试，不能只看语法检查通过。

同一 IP 为什么能放多个站点

假设 shop.example.test 和 docs.example.test 都解析到同一个 IP。浏览器建立连接时，目标 IP 和端口完全相同，Web 服务器还需要域名信息才能选中正确站点。

HTTP 用主机信息选内容

HTTP/1.1 请求会携带 Host，HTTP/2 和 HTTP/3 通常用 :authority。服务器先找到匹配当前监听地址和端口的虚拟主机集合，再按这个主机信息选择具体站点。名称不匹配时，通常会落入该监听地址的默认服务器。

默认服务器不是无关紧要的兜底。如果它直接展示第一个业务站点，攻击者使用未知 Host 也可能拿到真实内容，缓存键、绝对跳转、密码重置链接和代理路由还可能被错误的主机名污染。更稳妥的做法是建立明确的默认站点，对未知主机返回错误或直接断开，并让应用再做一次允许列表校验。

HTTPS 还要提前选证书

HTTPS 的难点在于 TLS 握手发生在 HTTP 之前。客户端通常在握手的 SNI 扩展里发送目标域名，服务器据此选择证书；加密通道建好之后，才读取 HTTP 主机信息并选择内容。

所以一次 HTTPS 虚拟主机选择实际有两次“报名字”：

1. TLS 阶段用 SNI 选择证书和握手参数；
2. HTTP 阶段用 Host 或 :authority 选择站点与路由。

两者应该一致。若 SNI 指向站点 A，HTTP 主机却声称站点 B，服务器、网关或应用需要有明确策略，不能默认把这种矛盾当正常请求。现代客户端普遍支持 SNI，因此多个 HTTPS 站点通常可以共享一个 IP 和 443 端口；只有特殊兼容需求、独立网络策略或隔离要求，才需要为站点分配不同 IP。

虚拟主机不等于安全隔离

多个站点写在不同 server 块或 <VirtualHost> 中，只是配置和路由分开了。它们仍可能共享进程用户、文件系统、日志管道、证书目录和系统资源。一个站点可以读取另一个站点文件时，Host 匹配再准确也没有隔离意义。

真正的隔离要继续落实到文件权限、运行用户、进程或容器边界、资源配额、密钥访问和网络策略上。隔离越强，部署与观测通常越复杂；是否值得，要看站点之间的信任等级，而不是域名数量。

配置项背后都在争夺资源

服务器配置最危险的方式，是从文章里抄一组“高性能参数”，一次性全部调大。每个数字都应回答三个问题：它限制什么资源？超过后请求会怎样？我们用哪个指标证明需要改变？

工作进程与连接上限

事件驱动服务器的工作进程数通常从可用 CPU 核心数附近起步，Nginx 的 worker_processes auto 会按环境选择数量。但这不是定律。进程受 CPU 配额限制时，容器看到的核心数与真正可用算力可能不同；开启大量 TLS、压缩或脚本处理后，也要用实际 CPU 利用率和延迟验证。

worker_connections 表示每个工作进程可打开的连接数量上限之一，但反向代理请求往往同时占用客户端连接和上游连接，日志、文件和内部通信也需要文件描述符。因此“工作进程数乘以连接数”只是理论天花板，不是可承诺的用户并发。操作系统与进程的文件描述符限制还必须同步检查。

超时是在回收占用

“超时”不是一个总开关。至少要区分：

• 客户端多久还没发完请求头；
• 请求体两次读取之间允许停多久；
• 持久连接空闲多久后关闭；
• 连接上游允许等多久；
• 向上游发送数据时，两次写操作之间允许停多久；
• 等待上游响应时，两次读取之间允许停多久。

很多代理的读写超时约束的是连续两次 I/O 之间的空闲时间，不一定是整个请求的总时长。把它误当成总时限，会让你以为一个请求绝不可能运行超过 30 秒，结果流式响应每隔几秒发一点数据，连接可以持续很久。

超时太长会让慢客户端、失联上游和攻击流量长期占资源；太短会切断移动网络、大请求上传和合法长任务。对于真正耗时的业务，更好的做法通常是提交异步任务并返回任务 ID，而不是无限延长同步连接。

缓冲区是在换谁等待

请求缓冲开启时，代理可以先读完客户端请求体，再交给上游。好处是慢上传不会长期占住应用连接，也更容易在转发前执行大小检查；代价是增加内存或临时磁盘 I/O，首字节到达上游更晚，不适合需要边上传边处理的流。

响应缓冲开启时，代理可以快速读走上游输出，让应用尽早释放连接，再慢慢发送给客户端。代价同样是代理侧内存和磁盘，还会破坏服务器推送事件、逐块生成和实时日志这类流式体验。

缓冲区也不是越大越快。单连接多占几十 KiB 看起来不多，乘上几万连接就是实打实的内存。调优时应同时观察并发连接、进程常驻内存、临时文件 I/O、上游连接占用和首字节时间。

日志是诊断工具，不是流水账

访问日志至少要能关联一次请求并回答：何时到达、请求哪个主机和路径、状态码是什么、发送多少字节、总耗时多久、上游地址与上游耗时是多少。错误日志则记录解析失败、连接上游失败、文件权限和 TLS 等内部问题。

生产日志建议结构化并带请求 ID，方便跨代理与应用检索。不要记录密码、Cookie、Authorization、完整令牌或不必要的请求体。日志写得越多，存储与 I/O 越重，敏感数据暴露面也越大；采样、脱敏、轮转和保留期限要一起设计。

TLS 配置保护的是链路

TLS 配置包括证书与完整证书链、私钥权限、协议版本、会话复用和续期。常见起点是启用 TLS 1.2 与 TLS 1.3，并根据服务器版本和兼容目标选择加密参数。证书能证明客户端连接到了持有相应私钥的一方，TLS 能保护传输过程，但它不会替应用完成用户认证、权限检查和输入校验。

私钥应只让必要进程读取，不能放进静态目录、镜像公共层或日志。证书自动续期后还要确保服务器真正加载了新证书；“磁盘上的文件更新了”不等于线上连接已经使用新证书。

限流要先选对维度

限流常用漏桶或令牌桶思路：允许稳定速率，并给短时突发留出一定空间。关键不只是 10r/s 这个数字，而是按什么键统计。按客户端 IP 简单，但公司出口、校园网和移动运营商可能让很多用户共享 IP；在多层代理后，如果真实 IP 信任链配置错误，所有请求还可能被统计到同一个代理地址，或者被攻击者伪造绕过。

登录接口适合结合账号、设备、IP 和失败次数；昂贵查询可以按用户或租户限额；整个站点还需要总并发和上游容量保护。速率限制控制“单位时间进来多少”，连接限制控制“同时占住多少”，两者不能互相替代。

worker_processes auto;
worker_rlimit_nofile 65535;
 
events {
    worker_connections 8192;
}
 
http {
    client_header_timeout 10s;
    client_body_timeout   20s;
    client_max_body_size  10m;
    keepalive_timeout     30s;
 
    limit_req_zone $binary_remote_addr zone=per_ip:10m rate=10r/s;
 
    log_format request_json escape=json
        '{"time":"$time_iso8601",'
        '"request_id":"$request_id",'

这段配置仍然需要按服务器版本验证。比如 HTTP/2 指令语法会随版本变化，ssl_reject_handshake 也不是所有旧版本都支持。正确流程是先确认版本和模块，再做语法检查、小流量验证和可回滚发布。

性能调优先找排队发生在哪里

网站一慢，人们很容易先加工作进程、扩大缓冲区、把超时翻倍。这样有时会让图表短暂好看，也可能只是把排队从 Web 服务器搬到了数据库。

先定义你说的“快”

性能至少要同时看吞吐量和延迟。平均延迟会掩盖慢尾部，因此还要看 p50、p95、p99。同样的每秒 1000 个请求，如果 p99 从 80 毫秒升到 3 秒，用户感受已经完全不同。

还要分清时间花在哪：

• 建立连接与 TLS 握手；
• 等待请求进入工作进程；
• Web 服务器解析和路由；
• 连接上游；
• 上游计算或等待数据库；
• 代理缓冲与向慢客户端发送。

总耗时上升而上游耗时稳定，问题更可能在网络、队列或响应发送；总耗时和上游耗时一起上涨，则应继续检查应用与依赖。只有总耗时，没有上游时间和连接指标，很多结论都只是猜测。

看饱和指标，而不只看使用率

CPU 80% 不一定有问题，CPU 30% 也不代表系统健康。需要一起观察运行队列、上下文切换、事件循环延迟、内存与换页、打开文件数、监听队列溢出、活跃连接、磁盘延迟、网络重传和上游连接池等待。

尤其要警惕“某个资源还没满，所以它不是瓶颈”的推理。单线程事件循环占满一个核心时，整机总 CPU 可能只有八分之一；某个上游连接池只有 50 个连接时，Web 服务器还有大量空闲文件描述符也没用。

压测要像真实流量

只请求一个被内存缓存的小文件，测到的主要是网络与服务器框架，不代表真实 API。有效压测需要包含实际方法、请求体大小、缓存命中率、长短连接比例、TLS、新老客户端和上下游延迟，还要逐步增加负载，观察哪项指标先拐弯。

压测机本身也可能先耗尽端口、CPU 或带宽。若所有流量来自单个源 IP，限流和连接复用行为也与真实用户不同。结果异常好或异常差时，先验证“发压一侧是否健康”。

常见调整的真实代价

• 增加工作进程或线程：可能利用更多 CPU，也可能增加竞争、内存和上下文切换。
• 延长持久连接：减少握手，也让空闲客户端更久占用套接字。
• 启用压缩：省带宽、加 CPU；对图片和视频通常收益很小。
• 增大缓冲区：减少部分 I/O 次数，也让高并发下的总内存膨胀。
• 启用缓存：减轻上游，但要承担失效、权限隔离和陈旧内容风险。
• 关闭代理缓冲：改善流式响应，却让上游更容易被慢客户端拖住。
• 提高连接上限：容纳更多连接，也可能让数据库在更大的瞬时洪峰下崩溃。

调优顺序可以很朴素：固定测试场景，记录基线；一次只改一组相关参数；同时观察延迟、错误率与资源；确认改善来自目标瓶颈；再决定是否保留。没有基线和回滚方案的“优化”，只是一次风险更高的配置变更。

安全边界要落在每一层

Web 服务器经常位于公网入口，它能挡住一部分风险，但不能替后端包办安全。更可靠的做法是把边界放在每一层，并假设上一层传来的数据仍然需要验证。

网络与进程边界

只监听需要暴露的地址和端口；管理接口不要与公开站点共用无保护入口。主进程可能需要较高权限绑定低端口，但处理请求的工作进程应尽快降权。内容目录、日志目录和密钥目录使用不同权限，静态文件进程不应获得修改应用代码或读取全部密钥的能力。

容器可以增加隔离，但容器本身不是授权系统。仍要限制文件挂载、系统调用、网络访问、CPU、内存和进程数，并及时更新服务器与加密库。

HTTP 输入边界

为请求行、头字段、请求体、方法和解析时间设置限制。路径在映射文件前要规范化，避免 ..、编码差异、重复斜杠或符号链接绕出根目录。上传文件不能只相信扩展名和客户端声明的媒体类型，也不应直接放进可执行的静态目录。

对未知 Host 明确拒绝；生成绝对链接和安全回调地址时使用配置中的规范域名，不直接拼接未经验证的请求头。代理层需要删除或覆盖由客户端伪造的转发字段，只向受信上游传递经过整理的信息。

容量本身也是安全边界

请求速率、并发连接、请求体大小、上游队列、缓存空间和日志磁盘都可以被耗尽。限流、限并发、超时与大小限制并不是纯性能配置，它们共同决定一次恶意或异常流量能占用多少资源。

但限制太紧也会变成自己制造的拒绝服务。先用只记录不拦截的模式观察真实分布，再逐步启用规则；让被拒绝请求有单独指标，避免安全策略悄悄伤害正常用户。

让配置可以安全地上线

一份配置能启动，只说明语法正确，并且部分路径与文件存在；它还没有证明路由正确、证书匹配、容量足够。上线前至少完成以下检查：

• 对配置做语法检查，并输出服务器实际解析后的虚拟主机与模块信息；
• 用已知域名、未知域名、IP 直连分别验证默认站点；
• 检查 SNI 证书选择与 HTTP Host 路由是否一致；
• 覆盖静态文件、API、上传、长响应、错误响应和大请求边界；
• 验证日志中有请求 ID、总耗时和上游耗时，但没有凭证与隐私数据；
• 在接近真实流量的条件下观察文件描述符、内存、队列和上游容量；
• 准备可以快速恢复的上一版配置。

支持平滑重载的服务器可以让新工作进程读取新配置，旧进程继续完成手头请求，再逐步退出。这能减少中断，却不代表变更没有风险：错误路由、过紧限流和错误缓存策略照样会被平滑地发布出去。小流量验证、监控和回滚仍然必不可少。

现在再回头看“一个端口服务成千请求”，你会发现它不是某个神奇并发参数的功劳，而是一条完整链路共同工作的结果：内核区分连接，服务器调度就绪事件，TLS 和 HTTP 分阶段选择站点，路由决定处理程序，超时、缓冲和限流保护资源，日志则让我们看见排队到底发生在哪里。

下一次遇到 502、连接超时或“只在高峰期偶发”的问题，先别急着重启。沿着这条链路逐层确认：请求有没有到达监听端口、TLS 是否完成、Host 是否选中正确站点、路由去了哪里、上游等了多久。Web 服务器真正的价值，不只是把响应发回去，而是把每次请求放进一条可控制、可观察、能安全失败的路径里。