网站的CPU还很空，正常访客却逐渐连不上；如果入口堆着一批迟迟没有发完请求头的连接，换更大端口也未必解围。准备把Ethernet Servers的KVM VPS用作自管网站入口时，先要回答两个问题：请求头最多能等多久，连接限制从哪一刻开始计数。下面按NGINX官方文档拆开这两个门槛，再用明确假设算滞留规模，并把官网套餐、维护责任和退款条件放进同一张采购账。
同样写60秒，计时对象可能完全不同
排查nginx请求超时时间设置时，常见误判是把多个等待阶段当成一个总超时；再加上nginx连接数限制，容易让人以为所有已建立连接都已有相同保护。这里聚焦HTTP/1.1客户端向入口发送请求头的阶段，不讨论应用查询慢或上游返回504，也没有对商家的机器做压力测试。
据NGINX核心模块文档，client_header_timeout限制读取完整客户端请求头的时间，文档默认60秒；期限内没有传完，终止请求并返回408。“完整”包括头部结束边界。客户端已经连上、陆续送来了若干字节，都不能代替请求头已经读完这一条件。把该参数误解成每次来一个字节就重新给一分钟，会直接算错入口可能等待多久。
与之相比，client_body_timeout的文档默认也是60秒，却约束请求体相邻两次读取之间的等待，而非整份请求体的总传输时间；send_timeout默认60秒，约束相邻两次写出之间的间隔，而非整个响应的总时长。因此，一个持续缓慢上传的请求，可能一直没有触发请求体间隔超时，却早已超过业务允许的完整上传时间。需要总期限时，要另外设计应用或前置入口的约束，不能把一个读写间隔参数当成整单业务的倒计时。
这也决定了怎么取证。先区分TCP已建立、TLS握手完成、请求头读完、请求体读完和应用处理完成几个时间点。HTTP/2、HTTP/3及前方代理存在时，协议与超时还要按实际链路另验。若CDN已经把请求完整收下，再一次性转给源站，源站看到的发送节奏就与公网客户端不同，直接测源站得出的期限不能代表整条链路。
把连接上限调小，为什么未必挡住未完成的请求头
NGINX连接限制模块文档给出了关键边界：并非所有连接都计入limit_conn；只有服务器正在处理请求，且整个请求头已经读取完成时，才进入该模块的计数范围。于是，“限制每个IP同时处理多少请求”和“限制还在慢慢发送请求头的连接”是不同工作。已有配置里出现limit_conn，不足以证明后一阶段已被保护。
不要由此推导limit_conn没有用。请求头完整以后，它仍可对既定键值限制并发；在HTTP/2和HTTP/3下，官方文档还说明每个并发请求会单独视作一个连接计数。只是验收必须覆盖计数开始之前的阶段。若入口前方有可信代理，按客户端IP还是代理IP归组也要先核实；没有正确还原来源，多个正常用户可能共享一个额度，甚至全部流量被误算到一个键上。
采购中的另一处误区，是把产品页的网络层DDoS防护数字直接当作这类请求的处置能力。Ethernet Servers现行VPS页面写有5Gbps网络层防护，但这不是本篇慢请求头场景的效果实测，也没有证明所有应用层等待都由商家处理。若上游防护是否终止HTTP、是否有应用层限额和日志都没有说清，仍应由自管入口承担对应配置与观察责任。
一笔只计算滞留数量的预算
假设在隔离验收环境中，每秒新出现4条一直不能完成请求头的连接，其他提前退出因素忽略，且观察足够久进入近似稳定状态。用“平均进入速率乘平均停留时间”估算：等待60秒约占240条，等待15秒约占60条，差额180条。这些是示例输入的推导结果，不是商家的连接能力，也不是推荐所有业务照抄15秒。合法用户的弱网、移动网络和前置链路同样可能受到缩短期限的影响。
这个公式只回答数量，没有给出内存字节数。每条连接的状态、TLS、缓冲与日志开销取决于版本和配置；用一项默认缓冲大小乘所有连接就宣称整机耗尽，会漏掉按需分配与其他开销。应在目标实例记录进程驻留内存、开放连接数、正常请求延迟和错误日志，比较修改前后增量。若来源规模持续扩大，单机缩短等待也可能不够，采购就要转向前置接入能力，而不能只在同一台VPS上无限提高上限。
Ethernet Servers的两个档位，要为哪一种增量付钱
2026年11月3日本轮读取的官网VPS页面，月付展示如下。价格、规格来自同一产品卡片配对，未将相邻卡片的金额串到一起；静态页面同时包含订购与Unavailable元素，无法仅凭此确认即时库存和结算可用性。因此表格用于询价对照，不构成可购或促销承诺。
| 官网月付档 | 计算与存储 | 出站额度 |
|---|---|---|
| 1GB：3美元 | 1核心、55GB SSD | 3TB |
| 2GB：6美元 | 1核心、80GB SSD | 5TB |
两档都列有10Gbps端口，但官网FAQ进一步说的是宿主机以10Gbps上联。不能把它写成每台VPS独享10Gbps或全天保底吞吐。CPU从1GB档到2GB档仍为1核心，内存、磁盘和出站额度发生变化；若瓶颈是错误的等待边界，升到2GB不会自动改写NGINX规则。若已经测得正常峰值与异常残留叠加造成内存不足，增加内存才有可验证的用途。
以两档展示月价保持不变、连续买12个月、没有税费和额外服务为假设，主机账分别36美元和72美元，差额36美元。这是月付外推，不是年付订单报价。官网另有不同周期折扣入口，不应把月付外推当成实际年付价；优惠码适用范围、续费和税额均以结算页为准。若两个月维护工时就超过这笔差额，选择更小机器却没有维护人，并不一定更省。
适合的采购场景，是有人员能自行维护HTTP入口、需要自定义超时与日志、愿意先完成小流量验收的网站。希望买来就由商家承担应用层防护、没有权限调整前置代理，或必须承诺持续大带宽的业务，暂时不能只凭这张参数表决定。需要核对当前候选的读者，可通过查看Ethernet Servers 1GB与2GB KVM的内存、SSD和出站额度（推广链接）询价，先问清可开通节点与结算条款。
官网明确将服务描述为unmanaged，会合理帮助处理能迅速解决的问题；这不能等同于已经承诺替每个网站设计、监控和回退超时配置。安装控制面板也不自动包含许可证，页面对所需有效授权另有说明。维护责任应写到具体动作：谁读取错误日志、谁改配置、谁判断正常用户被误伤、谁在业务告警后回退。只有“有技术支持”这句话，无法计算交付工时。
验收单按请求进度写，付款条件按责任写
本轮检索NGINX官方首页，10月21日公告列出1.31.8主线版发布。它提供了近期版本维护背景，并不证明新版本会替用户选择正确超时。部署验收先记录实际版本、模块与生效配置，不因更新就跳过原有边界测试。本篇不把版本公告包装成商家促销，也不声称任何实例已经升级。
测试只在自有隔离实例或商家明确许可的窗口内，以极少量连接核对语义。第一组完整且正常发送请求，记录成功和延迟；第二组发送请求头的一部分后停止，核对终止时点及入口日志；第三组在期限内缓慢发送但最终补齐，验证合法边界；第四组先完整发送请求头，再让请求体读取间隔超过设定值。后两组的区别能判断操作人员是否真的把整头期限和请求体间隔分开。不要用连接仍显示已建立，或一次浏览器刷新成功，代替这些结果。
记录至少包含实例与域名、经过的入口层、协议、开始时间、最后一次收发时间、结束时间、日志理由，以及同一窗口正常请求的结果。客户端最终只看到关闭而没读到408，并不能单独证明服务端没有按请求头超时处理；应对照服务端日志和连接过程。若只测直连源站，验收报告须保留这一范围，再经公网代理复验。每次只改一个相关门槛，并保存可恢复配置，才能解释误伤率从哪里变化。
给商家的售前工单可以明确问：当前节点能否开通这两个月付档，10Gbps究竟由哪些实例共享，3TB与5TB如何计量及超额处理；前方防护能否识别应用层慢连接，是否允许按约定做少量边界测试；自管入口的配置与日志权限是否完整；升级是否影响地址和数据，后续能否降档。官网FAQ当前写的是支持升级、不支持降级，这会使一次为排错而升档变成持续费用，不能假定验证失败后随时退回原档。
最后核对退款，而不是把“试用”理解成没有条件。条款列出VPS退款窗口60天，同时限定每人一次、仅首单，违反服务条款不适用；独立备份也仍由客户准备，官网每日异地备份最多7天恢复点不保证每份都完整可恢复。需要比较维护与退出成本，可用核对Ethernet Servers可自管KVM的开通、升档及首单退款条件（推广链接）取得当前书面答复。先收齐可复现的请求期限记录、正常用户影响和退款资格，再决定保留小档、增加内存，还是改选有人负责前置入口的方案。
资料来源
以下为本轮读取的官方资料；规格、价格和条款可能变化，本文未完成付款或商家实例实测。
Ethernet Servers官网：VPS套餐、宿主上联与自管说明
用户评论