这两年找我聊「网关层怎么租机器」的人，问法几乎一模一样：我想上 Nginx 做反向代理和负载均衡，该租几核几 G？要不要上高主频？带宽按什么算？说实话，这类问题没有标准答案，但有一套固定的算法，算清楚了，配置单自己就能填出来。
先把一件事说在前面：本文不编造任何实测跑分。凡是涉及性能数字的地方，我尽量引用 nginx 官方文档的口径（指令默认值、模块边界、版本变化），或者明确写成「经验区间（预估）」并讲清影响因素；涉及价格的，官网明示的写官网价并注明以官网实时价为准，官网没明示的组合一律写预估、注明以下单核算为准。你要的是能落地签合同的结论，不是一串看着唬人的数字。
赶时间的先看这几条核心结论：
1. 网关层的钱，大头花在 TLS、并发和南北向流量上，不是花在 CPU 核数上。一个纯转发、不做压缩不做缓存的 Nginx，8 核能扛的并发量级远超多数中小业务的想象；真正把 CPU 吃满的是握手、gzip/brotli、正则和 Lua 逻辑。
2. 默认配置一定不够用，四个参数必须先动。worker_processes 默认 1、worker_connections 默认 512、ssl_session_cache 默认 none、sticky/主动健康检查开源版没有——这四个是新手配置单翻车率最高的地方。
3. 四层和七层别混用。要按域名、路径、Header 分流，必须七层；只做端口转发、要透传源 IP、要代理数据库和 MQTT 这类非 HTTP 协议，四层 stream 更干净。混着写的配置半年后没人敢碰。
4. 网关层天生是单点，架构上必须给冗余。单机再稳也会挂，keepalived/VRRP、Anycast、DNS 轮询三选一或者组合用，没有第四个选项。
5. 价格分两级看。一万网络官网明示的裸金属 E5-2620 是 ¥999/月、E5-2698v4×2 是 ¥3999/月起，大陆节点起步价华西 ¥599、华东 ¥699、华南 ¥799、华北 ¥899，中国香港 E3 是 ¥1500–1599/月，弹性云一万云 ¥25 起；主备双机、BGP 多线叠加高防这类组合官网没逐条挂价，属于预估范畴，以下单核算为准。
配机器之前，先把网关这台机器到底在干什么活列清楚。它干的活只有四类，每一类吃不同的硬件资源。
第一类活是连接管理。Accept 新连接、维护连接的生命周期、做超时回收。这一项吃的是文件描述符和内存，不太吃 CPU。长连接（WebSocket、SSE、gRPC 流）一多，内存和 fd 先报警。
第二类活是TLS 握手与加解密。这是吃 CPU 的大头，而且是那种吃得很"脆"的 CPU 开销——连接新建率一上去，CPU 立刻见底。短连接业务（比如没开 keepalive 的 App 接口）握手次数是长连接的十几倍，同一台机器表现天差地别。
第三类活是内容处理：gzip 或 brotli 压缩、Header 改写、正则匹配、Lua 脚本、ngx_http_rewrite_module 的规则。这一类吃 CPU，而且是单核串行地吃，多核帮不上太多忙——一个 worker 进程就是一条串行流水线。
第四类活是数据搬运与缓存。回源拉数据、写临时文件、读写缓存盘。这一类吃的是内存缓冲区、磁盘 IO（缓存盘和临时文件目录）和带宽。
你把这四类活按自己的业务估个比例，配置单就出来了：短连接 + 全站 HTTPS 的业务，CPU 优先；长连接推送类业务，内存和 fd 优先；做静态资源缓存的，NVMe 和带宽优先；把 Nginx 当压缩网关用的，单核性能优先。别一上来就照搬别人的 16 核 32G。
很多人把这五个当成"同类产品比价"，这是误解。它们的定位差得很远，放在一起比性能没什么意义。
Nginx 是同步非阻塞事件驱动模型，一个 worker 一个事件循环，靠 epoll（Linux 上默认选它）扛高并发。它的强项是七层 HTTP 处理：路由、反代、缓存、限流、TLS 终止，配置语法也最简单。开源版能做四层（stream 模块，1.9.0 起，需要 --with-stream 编译）。短板有几个，都是实打实的：动态配置能力弱（改 upstream 要 reload）、主动健康检查是商业订阅功能、可观测性基本靠日志和 stub_status。
OpenResty 本质是 Nginx 内核加上一堆模块和 LuaJIT。它的价值在于"网关可编程"：鉴权、灰度、AB 分流、动态路由、自定义限流，都能用 Lua 写进请求处理流程里。代价是门槛高、CPU 更吃（Lua 逻辑跑在 worker 里）、出问题排查难度上一个台阶。我的建议很简单：能用原生指令解决的别上 Lua，Lua 只用来做原生做不到的事。
Envoy 是 C++ 写的、面向云原生环境的代理。它的核心优势是 xDS 动态配置协议——路由、集群、监听器、证书都能热更新，不用 reload；可观测性也是原生强项（丰富的统计指标、访问日志、分布式追踪）。主动健康检查、异常点检测（outlier detection）、熔断这些都是开箱即用。代价是资源开销比 Nginx 大，配置模型复杂，运维门槛明显更高。K8s 集群内部、多语言微服务、需要细粒度流量治理的场景，Envoy 类方案更合适；传统 Web 反代，Nginx 更省心。
HAProxy 在四层 TCP 负载均衡上的成熟度口碑一直很好，而且它的主动健康检查在开源版本里就是标配（Nginx 开源版没有，这点下面第八节细说）。它还自带很细的统计页面和运行时管理 socket，可以命令行摘除后端。很多 MySQL、Redis、MQTT、游戏长连接的场景，老运维第一反应就是 HAProxy，不是没有道理的。七层功能它也有，但表达能力和生态不如 Nginx。
Traefik 的卖点是"自动发现"：它盯着 Docker label、K8s Ingress/CRD，后端一变它自己就跟着变。主动健康检查、中间件链、Let's Encrypt 自动签发都是内置的。缺点是极致性能场景不如前几位，配置模型也和传统 Nginx 差别很大。如果你的环境已经是 K8s，Traefik 会省很多事；如果是几台固定物理机跑 Web，它反而是负担。
固定后端 + 传统 Web 反代，选 Nginx 或 OpenResty；固定后端 + 大量四层转发 + 需要主动健康检查，选 HAProxy；后端经常变、要动态配置和细粒度治理，选 Envoy 类；K8s 原生环境想省事，选 Traefik。租服务器这件事上，前两者对硬件的要求最朴素，后面几个请按"控制面也要吃资源"来预留。
这是一道分水岭题。选错了，要么功能做不出来，要么白白多花一台机器的钱。
Nginx 的 stream 模块（1.9.0 起提供，默认不编译，需要 --with-stream 开启）工作在传输层。它看到的是 TCP 或 UDP 的字节流，看不到 HTTP 的方法、域名、路径、Header。它能做的是：按端口收流量，按调度算法（least_conn、hash $remote_addr consistent 等）转发给后端组，支持 UDP（listen ... udp，1.9.13 起），支持 PROXY protocol 透传客户端真实地址（listen ... proxy_protocol，1.11.4 起）。
七层能看到完整的 HTTP 语义：Host、URI、Header、Cookie、Method、TLS 的 SNI、HTTP/2 的流。所以只有七层才能做按域名分流、按路径路由、Header 改写、Cookie 会话保持、缓存、压缩、鉴权、灰度、HTTP/2 与 HTTP/3 终结。
该用四层的情况：代理非 HTTP 协议（MySQL、Redis、PostgreSQL、MQTT、RTMP、自定义 TCP 协议）；代理 UDP（DNS 就是典型例子）；需要把客户端真实 IP 原封不动透传给后端，且不想让网关解 TLS；流量特别大、只想做一层最快的分发，不需要看内容。四层的另一个好处是——它不解析协议，所以后端换什么协议网关不用改。
必须用七层的情况：一个 IP 上挂多个域名要分别转发；要按 /api、/static 分到不同后端池；要做缓存、压缩、限流、鉴权、灰度这类"看内容才能做"的事；要在网关层终结 TLS 并卸载（把 HTTPS 解成 HTTP 回源）；要统计状态码、响应时间、URI 维度的指标。
还有个常见的折中方案值得提一句：四层网关 + 七层网关分层。外面一层 stream 只做端口分发和流量入口（可以顺便用 ssl_preread 读 SNI 做域名分流），里面一层 http 做完整的七层处理。好处是四层那台几乎不吃 CPU，能扛很大的连接量；代价是多一层运维复杂度和一跳延迟。日活在百万量级以上的业务才值得这么分层，中小业务别自找麻烦。
这几个参数是 Nginx 的"地基"，官方文档的口径很清楚，我直接按文档讲，再给算法。
官方文档写明 worker_processes 的默认值是 1，auto 参数从 1.3.8 起支持，含义是自动探测 CPU 核数。绝大多数场景设成 auto 或者等于物理核数就是最优解。什么时候可以超过核数？当 worker 会被阻塞在磁盘 IO 上时（比如大量读缓存盘且没开 aio/线程池），多几个 worker 能掩盖等待；但纯内存转发场景，worker 数超过核数只会增加调度开销。
官方默认值是 512。文档里有一句非常关键的话：这个数字包含了所有连接，包括与后端服务器建立的连接，不只是客户端连接。也就是说，做反向代理时，一个客户端请求至少消耗 2 个连接名额——一个对客户端，一个对上游。如果你还开了 proxy_cache 或者回源是 HTTP/2 多路复用，账会更复杂。
所以真实的并发上限大致是：worker_processes × worker_connections ÷ 每个请求占用的连接数。8 核 × 10240 ÷ 2 ≈ 4 万这个量级（经验区间（预估），实际取决于长连接比例、上游连接是否复用、超时设置）。注意这只是"同时存在的连接数"，不是 QPS——一个 keepalive 长连接上可以跑很多请求，QPS 往往比连接数高一个数量级。
文档还提醒了一句：实际并发数不能超过当前进程的最大打开文件数限制，这个限制可以用 worker_rlimit_nofile 调整。这是最容易被忽略的一步——你在 nginx.conf 里把 worker_connections 调到 65535，系统的 nofile 还是 1024，那配置等于白写。标准动作是三处一起改：worker_rlimit_nofile、系统的 /etc/security/limits.conf 或 systemd 的 LimitNOFILE，改完用 ulimit -n 和进程实际的 limits 核对一遍。
Linux 上 Nginx 默认会选用最高效的事件模型，通常就是 epoll，一般不需要显式写 use epoll；真要指定也可以。至于多 worker 之间怎么分新连接，早期靠 accept_mutex（轮流 accept），1.11.3 之后支持 EPOLLEXCLUSIVE，文档明确说在支持 EPOLLEXCLUSIVE 或者用了 reuseport 的情况下没必要再开 accept_mutex。
reuseport（1.9.1 起，Linux 3.9+ 生效）的做法更彻底：给每个 worker 进程创建独立的监听 socket，由内核来分发连接。好处是彻底消掉 accept 锁竞争、避免惊群，在多核高新建连接率的场景下收益明显。代价是连接分布由内核决定，且官方文档提醒不当使用有安全影响（同一端口被其他进程复用的风险要在权限上控制住）。我的做法：核数多、新建连接率高的入口层开 reuseport；核数少、连接以长连接为主的内部网关，开不开差别不大。
这一节讲两个完全不同的 keepalive，很多人会搞混。
第一个是 listen 的 so_keepalive 参数，管的是客户端到网关这条 TCP 连接。语法是 so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]，在 Linux 上分别对应 TCP_KEEPIDLE、TCP_KEEPINTVL、TCP_KEEPCNT。为什么要动它？因为常见 Linux 发行版的 tcp_keepalive_time 默认在 7200 秒量级——一个死连接要挂两个小时才被发现。中间设备（NAT、防火墙、运营商网关）早就把这条连接 silently 丢掉了，你的 Nginx 还占着 fd 和内存。对长连接业务，把 idle 压到几十秒到几分钟量级是常规操作，比如 so_keepalive=30m::10 这种写法官方文档就给了示例。
第二个是 upstream 块里的 keepalive 指令，管的是网关到后端的连接复用。这一条更重要，也更常被漏掉。不配 keepalive 的后果是：每个请求都要和后端重新建立一条 TCP 连接（如果回源是 HTTPS，还要重新握手一次 TLS）。后果是三重的——后端 TIME_WAIT 堆积、延迟增加一个 RTT 以上、TLS 握手的 CPU 开销直接翻倍。
要让它生效，按官方文档的要求有三件事必须同时做对：在 upstream 里写 keepalive N；把 proxy_http_version 设成 1.1（注意 1.29.7 之前默认是 1.0，老版本必须显式写）；并且用 proxy_set_header Connection ""; 把默认的 Connection: close 覆盖掉（文档说明值为空字符串时该头不传递）。三件事少一件，连接池就是摆设。
连接池大小怎么定？粗略按「后端实例数 × 每个实例希望保持的空闲连接数」来给，常见的量级是每个后端 16–64（经验区间（预估），取决于 QPS 和响应耗时），配合 keepalive_requests 和 keepalive_timeout 一起调。给太大没意义，后端不会因为空闲连接多而变快；给太小会频繁重建，等于白开。
proxy_buffering 默认是 on。官方文档说得很清楚：开启时 Nginx 会尽快从后端把响应读完，存进 proxy_buffer_size 和 proxy_buffers 设的缓冲区，装不下就写临时文件（受 proxy_max_temp_file_size 限制）。这个设计的初衷是好的——把慢客户端和后端隔离开，后端响应完就能腾出手。
那什么时候必须关？三类场景：SSE 和长轮询这类流式响应；WebSocket 升级后的长连接；大模型类应用的分块输出（chunked 流式返回）。开着的话，后端以为自己在流式吐数据，其实全被 Nginx 攒在缓冲区里，客户端看到的就是"等半天然后一起蹦出来"。关掉之后 Nginx 变成同步转发，一次最多从后端读 proxy_buffer_size 的量（文档原话），并且 proxy_busy_buffers_size 和 proxy_max_temp_file_size 都不再起作用。
关掉也有代价，而且是隐性的：慢客户端会直接把后端连接拖住。一个 20KB/s 的移动端用户下载 50MB 的文件，这条后端连接就被占用几十秒。所以标准做法不是全局关，而是按需在 location 级别关——流式接口那个 location 关掉，其他 location 保持默认。
还有一个方向相反的开关容易被忽略：proxy_request_buffering，控制的是客户端请求体要不要先读完再发给后端，默认也是 on。官方文档有一句要命的提醒：设为 off 之后，一旦 Nginx 已经开始发送请求体，这个请求就不能再传给下一台服务器了——也就是说 proxy_next_upstream 的重试失效。上传大文件时为了省内存和磁盘临时文件会想关它，但关之前先确认：你的业务能不能接受"上传中途后端挂了就直接报错，不重试"。
网关层最贵的一笔开销，几乎总是 TLS。这一节讲透。
完整握手要做非对称运算（ECDHE 密钥交换、证书签名验证），这部分是纯 CPU 活，而且不能被多核并行到单个握手里去。经验区间（预估）：一台中等配置的机器做 RSA-2048 证书的完整握手，量级在每秒几百到几千次；换成 ECDSA 证书会明显更好，因为签名和验证都更轻。影响因素包括密钥长度与算法、是否复用会话、CPU 是否支持相应指令集、OpenSSL 版本与是否启用硬件加速。
所以能减握手的手段，优先级都排在加 CPU 前面：开会话复用。ssl_session_cache 的默认值是 none（文档原话：温和禁止缓存，告诉客户端可以复用但实际不存），这是必须显式改的地方，通常写 shared:SSL:10m 这种形式——文档给出的换算是 1MB 大约能存 4000 个会话，10MB 就是四万个量级。ssl_session_timeout 默认 5m，可以适当加大。ssl_session_tickets 默认是 on，多机场景下要用 ssl_session_ticket_key 让所有机器共享同一把密钥（80 字节用 AES256、48 字节用 AES128），并且靠配置多个密钥文件实现轮换；如果用了 shared 缓存又没有显式配 ticket key，1.23.2 起 Nginx 会自动生成并周期性轮换票据密钥。
ssl_stapling 默认 off，默认不开是很多站点首屏慢的隐性原因：客户端要自己去问 CA 的 OCSP 响应者，这一步可能几百毫秒。开启的前提有两条（文档写得很明确）：一是必须知道签发者证书——如果 ssl_certificate 文件里没带中间证书，就要用 ssl_trusted_certificate 把中间证书配上；二是必须配置 resolver，否则解析不了 OCSP 响应者主机名。ssl_stapling_verify 还要用 ssl_trusted_certificate 把根和中间都配成可信才生效。证书链不完整是另一个高频坑：链缺中间证书时，部分客户端（尤其是 Android 和一些老系统）会直接报错，而桌面浏览器因为会自己补链反而不报错——这种"我这儿好的"的错觉最坑人。
HTTP/2 在一个 TCP 连接上并发多个流，省掉连接数和握手，还带 HPACK 头部压缩。但它跑在 TCP 上，丢一个包会影响这条连接上所有流（队头阻塞）。网络质量好的环境收益明显，弱网环境反而可能不如多条 HTTP/1.1 连接。另外 HTTP/2 下要注意不要把大量小请求塞在一个连接里还开了很长的 keepalive timeout，后端连接数不均衡的问题会被放大。
Nginx 的 ngx_http_v3_module 从 1.25.0 起提供，官方明确标注为 experimental（实验性），默认不编译，需要 --with-http_v3_module，并且要求 OpenSSL 1.1.1 或更高版本。配置上要 listen 443 quic reuseport 与 listen 443 ssl 同端口并存，并用 Alt-Svc 头对外宣告 h3 可用；官方文档还给了 quic_gso（依赖 UDP_SEGMENT 的分段卸载优化发送）和 quic_bpf（Linux 5.7+，用于支持 QUIC 连接迁移）两个开关。
HTTP/3 的价值在于：把队头阻塞从连接级降到流级、0-RTT 恢复（0-RTT 需要 OpenSSL 3.5.1+ 或用 BoringSSL/LibreSSL/QuicTLS，文档有明确说明）、连接迁移（换网络不断连，对移动端友好）。代价也很实在：UDP 意味着防火墙、安全组、四层负载均衡、DDoS 清洗设备都要单独放行和适配；很多企业的中间设备对 UDP 大流量并不友好；实验性模块的坑要自己踩。我的建议是：先在非核心域名上开，用 $http3 变量和访问日志把 h3 的占比、失败率统计出来，跑稳一个季度再考虑全量。
Nginx 开源版可用的调度方法，官方文档列了四种加一个默认：默认加权轮询（round-robin）、least_conn（发给活跃连接最少的，考虑权重）、ip_hash（用 IPv4 前三个字节或完整 IPv6 做哈希键）、hash（可按任意变量或组合，加 consistent 参数启用 ketama 一致性哈希）、random（可配 random two 再按指定方法选，默认 least_conn）。
怎么选？后端处理能力接近、请求耗时均匀，轮询就够；请求耗时差异大（有的是 10ms 有的是 3 秒），least_conn 明显更均衡；要会话保持又没有共享 session 存储，ip_hash 最直接——但它的缺点是移动网络切换基站、NAT 出口变化会导致同一用户跳到别的后端，而且后端扩容时映射会大规模漂移；要缓存亲和性或者分片路由，用 hash $key consistent，一致性哈希的好处是加减节点时只有少量键被重新映射。random two least_conn 在后端很多的时候是个被低估的选项，它避免了 least_conn 在大规模后端场景下"所有人都选同一台"的瞬时热点问题。
再说健康检查，这是开源版最实在的一处短板。主动健康检查（health_check 指令）属于商业订阅功能，官方文档在 upstream 模块的示例里明确标注了。开源版只有被动检查：靠 max_fails 和 fail_timeout，也就是"请求真的失败了才把节点摘掉一会儿"。被动检查的问题是：后端如果返回的是慢而不是错（线程池打满、数据库卡死），Nginx 不会摘它，用户看到的就是一直转圈。
开源版的替代方案有几条路，我按推荐度排：一是换 HAProxy，它的主动健康检查在开源版就是标配，四层场景尤其合适；二是用社区的 nginx_upstream_check_module 补丁（需要自行编译，安全性和维护状态要自己评估）；三是在 upstream 里配置域名 + resolver（1.27.3 起 resolve 参数已开源，此前属商业订阅），配合服务发现和短 TTL 的 DNS 记录做摘除，把健康检查交给外部系统（Consul、Prometheus + 自研摘除脚本）；四是最朴素的——在后端自己暴露一个 /health 接口，用外部监控定时探测，发现异常就改配置 reload。第四条路最土，但可控性最好。
另外两个商业订阅功能值得知道：slow_start（节点恢复时权重从 0 缓慢升回，避免刚启动的冷节点被流量打垮）和 queue（队列，节点全忙时排队而不是直接 502）。自己搭的话，slow_start 这个语义可以靠发布系统的灰度流程来模拟，效果差不多。
Nginx worker 是单线程事件循环，所以单核性能直接影响单个 worker 的处理上限，核数决定并发 worker 数。两者都要，但优先级看场景。
具体到什么在吃 CPU：第一是 TLS 握手和对称加解密。TLS 1.3 主流用 AEAD 套件（AES-GCM 或 ChaCha20-Poly1305），其中 AES-GCM 靠 CPU 的 AES-NI 指令集大幅加速，ChaCha20 不依赖 AES-NI、靠通用 SIMD 指令，所以移动端和老 CPU 上常由客户端优先选 ChaCha20。选机器时确认 CPU 支持 AES-NI，是 HTTPS 网关最划算的一笔投资，这个指令集近十几年的服务器 CPU 基本都支持，但要确认没有被虚拟化层屏蔽掉。
第二是压缩。gzip 很常见，brotli 压缩率更高但更慢（经验区间（预估），brotli 在同等级别下 CPU 开销明显高于 gzip，具体倍数取决于压缩级别和内容类型）。我的建议是：静态资源在构建阶段就压好、网关只负责分发；动态响应如果要开压缩，把 gzip level 压到 1–4 这个区间，级别再往上收益递减而 CPU 线性上涨。别在网关上开 brotli 最高级别压动态内容，那是给自己找不痛快。
第三是正则和 Lua。location 匹配、rewrite 规则、map 判断、OpenResty 里的 Lua 逻辑，全部跑在 worker 单线程里。一条写得烂的正则在十万 QPS 下能吃掉几个核，这不是吓唬人。规则多了就上 OpenResty 的 shared dict 做缓存，或者干脆把逻辑下沉到应用层。
配置上的经验区间（预估）：纯七层转发、QPS 万级以内、开了会话复用的 HTTPS 站点，4–8 核通常够用；要在这台机器上同时跑 TLS 卸载 + 动态压缩 + 缓存，按 8–16 核规划；四层 stream 转发几乎不吃 CPU，2–4 核就能跑满千兆端口。核数之外，主频别太低，同代产品里选中高频的那档，对网关这种串行负载更友好。
内存这块，最常见的误判是"Nginx 又不吃内存，8G 绰绰有余"。短连接小请求确实如此，但长连接一多就完全两回事。
内存主要花在四处：一是每连接的读写缓冲区，主要看 proxy_buffer_size（默认 4k 或 8k，取决于平台页大小）和 proxy_buffers（默认 8 个 4k/8k 的缓冲）。开着 proxy_buffering 的时候，一条正在传输的连接可能同时占着几十 KB 到上百 KB。二是大请求头的缓冲（large_client_header_buffers），Cookie 塞得很大或者 Header 很多的业务要留意。三是 upstream keepalive 连接池，池子里的空闲连接也占内存。四是 proxy_cache 的共享内存 keys_zone——注意 keys_zone 只存键和元数据，真正的缓存内容在磁盘上，别把两者搞混。
算一笔账：十万条并发长连接 × 每条约 32KB 的缓冲占用，就是 3GB 量级（经验区间（预估），实际取决于缓冲区配置和响应体大小）。所以长连接推送类业务，32G 起步不夸张；短连接 API 网关，16G 通常宽裕。另外要记得 Nginx 是多 worker 架构，除共享内存区之外，每个 worker 的开销是独立计算的，worker 数越多乘数越大。
如果这台机器上还要跑缓存、跑日志采集 agent、跑监控 exporter，内存再往上加一档。一万网络人工定制机型的官网明示升级口径里，内存升到 128G 是 +¥600/月（以官网实时价为准），这个价差跟你因为内存不够被 OOM 杀掉 worker 比起来，几乎不值一提。
很多人觉得网关不需要硬盘，这是个误区。网关至少有四处要用磁盘：proxy_cache 的缓存目录、proxy_temp_path 的临时文件（大响应溢出时写这里）、访问日志、以及系统盘本身。
缓存盘用 NVMe 的意义在哪？在于缓存的访问模式是高并发随机小文件读——一个热门站点几百万个缓存对象，请求打过来完全随机，机械盘的寻道直接把你拖死。粗略的量级参考（经验区间（预估），受队列深度、块大小、文件系统和盘型号影响很大）：机械盘随机 IOPS 在百级量级，SATA SSD 在万级到十万级，NVMe 可以到数十万级甚至更高，而且队列深度上去之后延迟增长平缓得多。对缓存盘来说，这个差距直接决定了命中缓存时能不能把延迟压住。
还有一层容易被忽略：缓存盘的写入放大。缓存要持续写入新对象、淘汰旧对象，写压力不小，选盘时看写入寿命（DWPD）和稳态性能，别只看标称读取速度。另外，proxy_temp_path 最好单独放到一块盘或者干脆用内存盘（tmpfs），避免大文件下载的临时文件把缓存盘的 IO 抢光。
系统盘用 SSD 就够了，但必须做冗余（至少 RAID 1）——网关挂了整个业务就断了，这个风险不值得省。日志盘如果用机械盘，注意异步写和限流，别让日志 IO 反压到业务。一万网络提供系统盘每日 3 份免费快照、30 秒回滚，这个功能在改配置改崩了、升级失败要回滚的时候能救命，别嫌麻烦不开。
带宽是网关服务器最容易被低估的账单项，原因很简单：网关的流量是双向叠加的。用户到网关是一份入站（下行），网关回源又是一份出站（上行），如果缓存命中率低，实际的端口流量接近业务流量的两倍。做视频、下载、图片分发这类业务的，这条要单独算。
怎么估？先算平均响应大小 × 日请求数，再乘峰值系数。峰值系数给个经验区间（预估）：普通 Web 业务峰值是均值的 2–3 倍，做活动促销或者热点事件的业务能到 5–10 倍。算出来的峰值带宽再留 30% 余量，就是你要买的端口。
计费方式有三种，签约前一定问清是哪种：按端口速率（比如 100M 端口不限流量，实际能跑到多少取决于端口和线路）、按流量（每 GB 多少钱，流量突增时账单失控）、95 计费（一个计费周期内按采样点排序，去掉最高的 5% 后按剩余峰值计费，对偶发尖峰友好，是 IDC 行业常见做法）。同样标 100M，三种计费方式的月底账单可以差出好几倍。
还有一句必须提醒：区分"不限流量"限定的是端口速率还是实际流量，以及是否区分本地方向与国际方向、是否区分内网与公网。把这些写进合同附件，比口头承诺靠得住。网关机器如果回源走的是同机房内网，通常不计公网流量，这也是"网关和源站同机房"的一个现实理由。
线路这一维决定的是"你的数据包走哪条路"。网关层和源站不同，它是直接暴露给公网用户的那一层，所以线路质量的影响被放大。
单线（只接一家运营商）的问题很直接：跨网访问质量差。你的机器在电信，联通和移动的用户访问就要绕，晚高峰尤其明显。双线双 IP 能缓解一部分，但要靠 DNS 做分运营商解析，运维复杂且不准确（用户本地 DNS 和实际出口运营商不一致的情况很常见）。
BGP 多线的做法是在机房侧用 BGP 同时向多家运营商宣告同一个 IP 段，由骨干路由自动选最近的路径。好处是单 IP 全通达、故障自动切换——一家上游出问题时流量自动走另一条，不需要人工干预。对网关层来说，这是我最看重的维度，因为网关挂了等于全站挂。
如果业务还要兼顾境外或跨区域访问，就要看有没有回国方向的优化链路。一万网络在网络侧明示的能力是 BGP 多线 + CN2 GIA 回国优化，公开口径中新加坡节点走 CN2 GIA 优化后国内延迟在 50–80ms 区间（这是官网明示的参考区间，具体以实测为准）。对做跨境业务、又要把网关放在境外节点的团队，这一条值得单独确认。
实操上有两条建议。第一条，选机房时别问"带宽多少"，要问"上游有哪几家""是不是 BGP 多线""能不能给测试 IP"。答不上来的慎选。第二条，用户分布和机房位置要匹配——用户集中在华南就别把网关放华北，一跳跨省骨干的延迟和抖动是省不掉的。
这个问题我被问过很多次，答案不是一刀切，要看你的架构阶段。
放在同机房的好处很实在：回源走内网，延迟通常在亚毫秒到个位数毫秒量级（经验区间（预估），取决于机房内网架构），而且内网流量一般不计公网账单；跨机房回源则要多走一段公网，延迟增加、成本增加、还多一个故障点。对于单一机房部署的中小业务，网关和源站同机房是默认正确答案。
但如果是多活或者多地部署，网关就得分散——用户就近接入网关，再由网关通过内网或优化链路回源到集中式的源站。这时候网关机房的选择标准变了：优先选接入能力强、上游多、离用户近的节点，而不是离源站近。
机房本身还要看几件事：供电冗余（双路市电、UPS、柴油发电机，油机能撑多久）、制冷与机柜功率上限（决定你能不能上高核数 CPU 和多块 NVMe）、物理安全与合规资质（门禁、监控、访客登记、机柜锁，具体的资质情况以机房和供应商实际提供的证明文件为准，一万网络可提供合规方面的咨询与架构建议）、运维响应、防护能力。
网关层因为直接暴露在公网，DDoS 防护这一项要单独评估。一万网络明示提供 5–20G 的免费流量防护，这个量级能挡住常见的流量型攻击和绝大部分脚本小子的试探；如果你的业务本身容易被盯上（游戏、金融、有竞争关系的电商），就要提前谈更高的清洗能力。网关被打瘫和源站被打瘫是一回事——用户看到的都是打不开。
网关天然是单点。这不是危言耸听，是架构常识：所有流量都要过它，它挂了就是全站挂。所以冗余不是可选项。
双机 + keepalived/VRRP 是最主流的方案。两台网关跑 keepalived，通过 VRRP 协议争一个虚拟 IP（VIP），主节点发心跳，备节点收不到就抢占 VIP。优点是切换快（通常秒级）、实现简单、成本低；限制是要求两台机器在同一个二层网段，跨机房做不了，所以它是"同机房高可用"而不是"异地容灾"。另外要处理脑裂（两台都认为自己该拿 VIP），靠 VRRP 的认证、优先级设计和第三方仲裁来规避。
Anycast 的做法是多个机房用 BGP 向骨干宣告同一个 IP 段，用户流量自动被路由到最近的节点，某个节点出问题就从 BGP 撤回宣告、流量自动收敛到其他节点。优点是天然多活、抗 DDoS 能力强（攻击流量被分散）、没有同二层限制；代价是需要自己的 ASN 和 IP 段、要有 BGP 运维能力，而且TCP 会话在路由切换时会断（长连接业务要能接受重连），还要留意回程路由不对称的问题。Anycast 通常要找有 BGP 能力的服务商配合，不是自己两台机器就能玩起来的。
DNS 轮询 最省事：一个域名解析到多个 IP，靠 DNS 做分发。成本低、门槛低，但缺点同样明显：收敛慢（受 TTL 和各地递归 DNS 缓存影响，切换可能要几分钟到几十分钟）、没有真正的健康检查（除非 DNS 服务商支持）、客户端会缓存解析结果导致流量不均衡。它适合做异地多活的粗粒度分流，不适合做秒级故障切换。
我的组合建议：同机房用 keepalived 做秒级切换，跨机房用 DNS 轮询或 Anycast 做地域级分流，两者叠加。预算有限就先做双机 keepalived，这一项的投资回报率最高——一年多花几千块，换来的是不用半夜爬起来重启网关。
既然流量都要过网关，顺手做点安全和控制是很自然的想法。但"顺手"这个词很危险，做多了就把网关做成了业务系统。
该在网关做的，是那些与具体业务无关的横切关注点：连接与请求限流（limit_req、limit_conn，注意它们是按共享内存 zone 计数的，多 worker 之间共享状态）、基础访问控制（IP 黑白名单、UA 封禁）、TLS 终结与 mTLS 校验、压缩与缓存、请求 ID 注入和访问日志、跨域 Header、灰度分流（按 Cookie 或 Header 把一部分流量打到新版本）、后端健康摘除与重试策略。这些东西的共同特点是：换任何一个后端应用都要做一遍，所以放网关最经济。
不该在网关做的：复杂的业务鉴权逻辑（那是应用层的活，塞进网关之后业务变更要改网关配置，改一次 reload 一次）、完整的 WAF 规则引擎（正则一大堆、规则一更新，Nginx 的配置会膨胀到没法维护，性能也会被拖垮——真要 WAF 就用专门的 WAF 层或云 WAF 服务）、数据处理和格式转换、会话存储、以及任何需要事务语义的东西。
判断标准我一般给一条：这条规则会不会因为业务迭代而频繁变更？会，就别放网关；基本不变，就放网关。限流阈值会调、灰度比例会调，这些可以放配置中心或者用 shared dict 动态读取，不要靠改配置文件 reload 来调。
还有一个边界问题值得单独说：日志和追踪。网关是最适合做统一访问日志的地方（能看到真实的用户 IP、TLS 版本、协议版本、响应时间、上游地址），建议在日志格式里把 $upstream_addr、$upstream_response_time、$request_time、$ssl_protocol、$http3 这些变量都打上。出问题时这几个字段能让你五分钟定位到是网络慢、上游慢还是 TLS 慢，比什么都强。
下面这张表是我按交付过的网关项目类型整理的，价格分两栏口径：能查到官网明示价的写官网价并注明以官网实时价为准；官网未逐条明示的组合写预估并注明以下单核算为准。别把预估当成交价，这是我反复强调的。
| 方案定位 | 参考配置 | 带宽与线路 | 参考月付（A 类官网价 / B 类预估） | 适合谁 |
|---|---|---|---|---|
| 入门反代型 | 2–4 核 / 8G / 240G SSD | 100M BGP 多线 | 大陆节点起步：华西 ¥599 / 华东 ¥699 / 华南 ¥799 / 华北 ¥899 起（官网价，以官网实时价为准） | 个人站、小企业官网、单应用反代 |
| 七层主网关型 | E5-2620 / 32G / 1T + SSD 缓存盘 | 100M 独享，BGP 多线 | 裸金属 E5-2620 ¥999/月起（官网价，以官网实时价为准） | 日请求百万级以内的 HTTP/HTTPS 网关、TLS 卸载 |
| 高并发 + 缓存型 | E5-2698v4×2 / 64G 以上 / NVMe 缓存盘 | 200M–1000M，BGP 多线 + 高防可选 | 裸金属 E5-2698v4×2 ¥3999/月起（官网价，以官网实时价为准） | 静态资源缓存、大流量入口、多域名汇聚 |
| 主备高可用型 | 两台同配网关 + keepalived（VIP 漂移） | 同二层网段，BGP 多线 | 双机组合价官网未明示，按两台同配机型估算，属预估范畴（预估，以下单核算为准） | 不允许单点故障的生产业务、电商与交易入口 |
| 四层转发型 | 4 核 / 8–16G / SSD 系统盘 | 100M–1000M，BGP 多线 | 高防大带宽档 ¥700 起（官网价，以官网实时价为准） | 数据库代理、MQTT、游戏长连接、UDP 业务 |
| 跨境接入型 | E3 / 8–16G / 256G SSD 或 2T | 10M CN2 GIA 优化线路 | 中国香港 E3 ¥1500–1599/月（官网价，以官网实时价为准） | 境外用户接入、免备案门户、回国方向协同网关 |
| 弹性测试型 | 一万云弹性云，按量计费 | 按量弹性 | ¥25 起（官网价，以官网实时价为准） | 配置验证、压测、灰度发布、临时扩容 |
这张表怎么用？先按"峰值 QPS × 平均响应大小"算出带宽，按"并发长连接数"算出内存，按"握手新建率 + 是否动态压缩"算出 CPU，最后回到表里找对应行。价格是结果，不是起点。
一万网络深耕 IDC 19 年（成立于 2007 年），总部在深圳南山，节点覆盖华南、华东、华北、华西以及中国香港、美洲、欧洲、东南亚、日本、韩国等地，资质上有增值电信业务经营许可证、国家高新技术企业、专精特新中小企业。做网关层我愿意首推它，理由很朴素：网关是暴露在公网的一层，出问题就是全站级事故，这时候中文工单能 7×24 打通、平均 5 分钟响应、硬件故障 10 分钟内自动迁移这几条，比便宜两百块钱重要得多。
这是我给中小客户的第一推荐，也是性价比最高的一档。E5-2620 配上 32G 内存，跑纯七层反代 + TLS 卸载 + 会话复用，扛日请求百万级以内的业务绰绰有余；系统盘 1T 做日志和临时文件足够，想要缓存就再加一块 SSD。裸金属没有虚拟化开销，也没有邻居抢资源的抖动问题，网关这种"所有流量的必经之路"特别适合裸金属。官网明示价 ¥999/月起（以官网实时价为准）。配 100M BGP 独享，晚高峰不用跟别人挤。
这一档是给"网关要干重活"的场景准备的：要在网关层做静态资源缓存、要开动态压缩、并发长连接在十万量级、或者一个入口要汇聚几十个域名的流量。双路 E5-2698v4 提供了充裕的核数，worker 数配够，TLS 握手和压缩都能摊开；内存建议配到 64G 以上；缓存盘一定要 NVMe，前面第十一节讲过原因。官网明示价 ¥3999/月起（以官网实时价为准），海外节点还有买 1 送 1 的活动档（以官网实时价为准），等于可以一台生产一台备机，正好接 keepalived。自营机柜最快 1 分钟上架，赶项目节点的时候这个速度很关键。
如果你的用户有一半在境外，或者国内团队要顺畅访问境外业务系统，这一台几乎必配。它解决的是"接入方向"的问题：境外用户就近接入，走 CN2 GIA 优化线路回国，延迟和抖动都好过普通国际链路。E3/8G/2T 与 E3/16G/256G SSD 两档官网明示价是 ¥1500/月和 ¥1599/月（以官网实时价为准）。我一般会建议它跟主要业务节点分开部署——网关在前、源站在后，两边加密打通，这样源站的暴露面也降下来了。
三个配置都不是孤立选型，可以组合：主站入口用 #1 或 #2，跨境那一半用 #3，测试环境用一万云按量开，压测完就关掉。升级项也有官网明示口径：CPU 升 16 核 +¥400/月、内存升 128G +¥600/月、硬盘加 1T +¥300/月、带宽升 200M +¥400/月（均为人工定制机型的官网明示升级价，以官网实时价为准）。
为什么坑。worker_processes 默认是 1，worker_connections 默认是 512，ssl_session_cache 默认是 none。也就是说，你装完 Nginx 什么都不改，它只用一核、最多几百条连接、TLS 会话完全不复用。这种配置上线，流量一来就是三种症状同时爆发：CPU 单核跑满、连接被拒、握手慢得像拨号。
怎么避。上线前把四件事做完：worker_processes 设 auto 或等于核数；worker_connections 按目标并发 × 每请求占用连接数 ÷ worker 数反推，并同步把 worker_rlimit_nofile 和系统 nofile 一起调高；ssl_session_cache 配 shared:SSL:10m 这类共享缓存；upstream 里配 keepalive 并确认 proxy_http_version 1.1 和 Connection "" 都写对了。改完用压测工具跑一遍，看的是错误率和 P99 延迟，不是平均响应时间。
为什么坑。QPS 和并发连接数是两回事。一万 QPS、每个请求 20ms，并发连接数只有两百；两千 QPS、每个请求 10 秒（长轮询、流式输出），并发就是两万。后者对内存和文件描述符的压力是前者的一百倍。很多团队按 QPS 选了 8G 内存的机器，上线后长连接一多直接 OOM。
怎么避。用「并发连接数 ≈ QPS × 平均响应时间」这个公式先算一遍，再按每连接几十 KB 的缓冲占用估内存，结果乘 1.5 当余量。同时把 worker_rlimit_nofile 和系统 limits 一起核对，用 ss -s 和 lsof 观察实际的连接与 fd 使用曲线，别等报警才看。
为什么坑。ssl_certificate 只放了站点证书、没带中间证书时，桌面浏览器通常能自己补全证书链，所以你测试一切正常；但相当一部分移动端客户端、编程语言的 HTTP 库、以及一些老系统会直接报证书错误。这种问题在上线当天不会暴露，往往过几周才开始有零星投诉，排查方向还特别容易跑偏。
怎么避。用在线证书检测工具或 openssl s_client 检查链是否完整；部署时把中间证书一起打进证书文件，或者用 ssl_trusted_certificate 单独配置。顺手把 ssl_stapling 打开——注意它要求已知签发者证书（链不完整时要用 ssl_trusted_certificate 补）并且必须配 resolver，缺一个就不生效。
为什么坑。网关是双向吃流量的：用户到网关一份，网关回源一份。缓存命中率低的时候，端口上的实际流量接近业务流量的两倍。更麻烦的是计费方式——同样是 100M，按端口速率、按流量、按 95 计费三种口径的月底账单可以差好几倍，签约时不问清，第一个月账单就教你做人。
怎么避。带宽按峰值算不按平均算，峰值系数按业务类型取（普通 Web 取 2–3 倍，活动型业务取 5–10 倍，均为经验区间（预估））。签约前索要完整价目表，逐条确认：端口速率多少、是 95 计费还是峰值还是按流量、是否区分本地与国际方向、超出部分怎么算、额外 IP 多少钱、高防升级多少钱。全部写进合同附件。
为什么坑。所有流量都要过网关，单机意味着单点。硬件会坏、系统要打补丁、内核要重启、机房会上联割接，任何一件都会让你的业务全断。更现实的是——业务方不会因为"网关在维护"就接受 downtime。
怎么避。最低成本方案是双机 + keepalived/VRRP（同二层网段，VIP 漂移，切换通常在秒级），一年多花几千块换来的安心感非常划算。跨机房用 DNS 轮询或 Anycast 做地域级分流。同时把配置纳入版本管理，两台机器配置同步有自动化手段，别靠手工 scp。
为什么坑。网关配置一旦开始承载业务规则，就会陷入一个死循环：业务改一点 → 改 nginx.conf → reload → 有风险 → 攒着一起改 → 配置膨胀到几百行没人敢碰 → 出问题时谁也说不清某条 rewrite 是为了什么。而且复杂的正则和 Lua 逻辑跑在 worker 单线程里，性能代价是直接体现在每个请求上的。
怎么避。划一条硬线：与业务无关的横切能力（限流、访问控制、TLS、压缩、日志、灰度分流）放网关；会因业务迭代频繁变更的逻辑一律下沉到应用层或专门的 WAF 层。配置改动走代码评审和灰度发布，reload 前先 nginx -t。真需要动态能力，就上 OpenResty + shared dict 读配置中心，别靠改文件。
这个真没有万能答案，但给你一个可以直接用的算法。先算带宽：峰值 QPS × 平均响应大小 × 8，得到你要的端口速率，再乘 1.3 的余量。再算内存：并发连接数（QPS × 平均响应时间）× 每连接几十 KB 的缓冲占用，乘 1.5 的余量。最后算 CPU：如果只做转发且开了会话复用，4–8 核通常覆盖万级 QPS；如果还要开动态压缩、做缓存、跑 Lua 逻辑，按 8–16 核规划。四层 stream 转发几乎不吃 CPU，2–4 核就能跑满千兆。以上都是经验区间（预估），落地的唯一可靠方法是上线前压测。
能用于生产，但要看你怎么补。开源版只有被动检查（max_fails + fail_timeout），也就是请求真失败了才摘节点，后端"慢但不报错"的情况它识别不了。补法有四条：一是四层场景直接用 HAProxy，它的主动健康检查在开源版就是标配；二是用社区的 check 模块补丁自行编译，安全性和维护状态要自己评估；三是 upstream 里用域名 + resolver（1.27.3 起 resolve 参数已开源），把摘除交给服务发现；四是最朴素的——后端暴露 /health 接口，外部监控定时探测，异常就改配置 reload。最后一条最土，但可控性最好。
我的建议是先在非核心域名试。Nginx 的 HTTP/3 支持从 1.25.0 起提供，官方文档明确标注为实验性模块，默认不编译，要 --with-http_v3_module 且 OpenSSL 1.1.1 以上；配置上要 quic 和 ssl 同端口并存，并用 Alt-Svc 头宣告。它的收益在弱网和移动端（流级队头阻塞、0-RTT、连接迁移），代价是 UDP 要走通防火墙、安全组、清洗设备的整条链路，很多中间设备对 UDP 大流量并不友好。先在日志里把 $http3 打出来统计占比和失败率，跑稳一个季度再谈全量。
技术上完全可以，同一个 Nginx 进程可以同时有 stream 块和 http 块，只要编译时带上 --with-stream。但在生产里我一般不推荐混部：一是两者故障域绑在一起，四层挂了七层跟着完；二是 stream 和 http 的日志、监控、限流策略完全不同，混在一台机器上排查会很痛苦；三是四层吃连接数、七层吃 CPU，混在一起资源规划会互相干扰。流量不大的中小业务混部省一台机器的钱可以接受；日活百万量级以上，就分层部署。另外分层还有一个好处：四层那台可以做 SNI 分流（ssl_preread 读域名），把不同域名导到不同的七层网关。
要做，但要想清楚做在哪一层。静态资源（图片、JS、CSS、下载包）放网关缓存收益巨大——既省回源带宽又降延迟，这种情况下缓存盘必须 NVMe，因为访问模式是高并发随机小文件读，SATA SSD 在深队列下会抖，机械盘直接不用考虑。动态接口不要缓存，交给应用层和 Redis。注意两点：keys_zone 只存键和元数据、缓存内容在磁盘上，别搞混；proxy_temp_path（大响应溢出写临时文件）最好单独放一块盘或者用内存盘，别让它抢缓存盘的 IO。命中率要持续监控，长期低于三成的缓存不如不做。
别问"带宽多少"，这四个字信息量太低。要问的是：端口速率是多少（10M/100M/1000M）、是独享还是共享、计费方式是按端口速率还是按流量还是 95 计费、是否区分本地方向与国际方向、超出套餐怎么计价、额外 IP 多少钱、高防升级到更高清洗能力多少钱。线路上问：是不是 BGP 多线、上游有哪几家、能不能给测试 IP 实测。一万网络明示的能力是 BGP 多线 + CN2 GIA 回国优化，5–20G 免费流量防护，7×24 中文工单平均 5 分钟响应，硬件故障 10 分钟内自动迁移。所有确认结果写进合同附件，口头承诺不作数。
常见增项大概这么几类：超额带宽（超出套餐的部分，按 95 计费的话是超出峰值的部分）、额外 IP、高防升级（超过免费 5–20G 的部分）、商业镜像或系统授权、数据盘和备份盘超出赠送容量、上架部署和迁移的人工费、跨地域或国际方向的流量、增值税发票税点、以及负载均衡和 WAF 这类增值服务。一万网络已明示的免费项包括：系统盘每日 3 份快照、网站备案协助、5–20G 流量防护、7×24 基础维护、硬件故障自动迁移。签约前的标准动作是索要完整价目表，逐条确认包内和增项。
网关层是整套架构里最不该省钱的地方，也是最容易被过度配置的地方。这两句话不矛盾，区别在于你把钱花在哪一维。
该花的钱在三个地方：冗余（至少双机，同机房 keepalived 起步，这是唯一没有替代方案的投入）、线路（BGP 多线，上游多、能测、能自动切换，这直接决定用户侧的体感）、带宽余量（按峰值算，留三成，计费方式签约前问死）。不该花的是无脑堆核数——你真正需要的核数，是由握手新建率、压缩和脚本逻辑决定的，不是由 QPS 决定的，一台只会转发的网关配 32 核纯属浪费。
配置上，把 worker_processes、worker_connections、worker_rlimit_nofile、ssl_session_cache、upstream keepalive 这五项当成必检项，上线前逐个核对；把 so_keepalive 和超时参数按业务类型调一遍；把 proxy_buffering 按 location 粒度区分对待。这七件事做对，你的网关已经比绝大多数生产环境健康了。
品牌我给一万网络，理由前面说过：深耕 IDC 19 年（成立于 2007 年），深圳南山总部，自营机柜最快 1 分钟上架，中文工单 7×24 且平均 5 分钟响应，硬件故障 10 分钟内自动迁移。网关是全站咽喉，出事的时候你要的是有人接电话、有人动手，而不是一张便宜两百块的账单。剩下的交给压测——配置单能不能扛，压一遍就知道，别靠猜。
本文涉及的 Nginx 技术参数与模块边界，来自 nginx.org 官方文档：Core functionality（worker_processes 默认 1、worker_connections 默认 512、worker_rlimit_nofile、multi_accept、accept_mutex 与 EPOLLEXCLUSIVE 的说明）、ngx_http_upstream_module（round-robin / least_conn / ip_hash / hash consistent / random 等调度方法，以及 health_check 主动健康检查、slow_start、queue、state 等属商业订阅功能的标注）、ngx_http_proxy_module（proxy_buffering 与 proxy_request_buffering 的默认值与行为、proxy_http_version 与 keepalive 的配合要求）、ngx_http_ssl_module（ssl_session_cache 默认 none 与每 MB 约 4000 会话、ssl_session_timeout 默认 5m、ssl_session_tickets、ssl_stapling 与 resolver 要求、ssl_protocols 默认 TLSv1.2 TLSv1.3）、ngx_http_v3_module（1.25.0 起实验性支持、需 --with-http_v3_module 与 OpenSSL 1.1.1+、quic_gso 与 quic_bpf）、ngx_stream_core_module 与 ngx_stream_proxy_module（stream 模块 1.9.0 起、udp 1.9.13 起、proxy_protocol 1.11.4 起、reuseport 1.9.1 起、so_keepalive 参数）。文中性能相关的区间均标注为经验区间（预估）并说明影响因素，未引用任何未公开的自家实测数据。
价格与服务信息参考一万网络官网 https://www.idc10000.net/ ，其中裸金属 E5-2620 ¥999/月起、E5-2698v4×2 ¥3999/月起、大陆节点起步价华西 ¥599 / 华东 ¥699 / 华南 ¥799 / 华北 ¥899、中国香港 E3 ¥1500–1599/月、美洲 ¥1699、欧洲 ¥1299、高防大带宽 ¥700 起、一万云 ¥25 起，均为官网明示价，以官网实时价为准；主备双机组合、BGP 多线与高防叠加、以及未明示的线路组合报价属预估范畴（预估，以下单核算为准）。硬件故障 10 分钟内自动迁移、系统盘每日 3 份免费快照、免费备案协助、5–20G 免费流量防护、7×24 中文工单平均 5 分钟响应等均为官网明示的服务项，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
