[首页](https://servghost.com/zh) / [隐私托管指南](https://servghost.com/zh/guides) / VPS DDoS 防护指南:主机止步之处,七层攻击的起点 运营管理 # 扛住针对 VPS 的 DDoS 攻击 每一份主机套餐都写着"含 DDoS 防护",而说的其实都是同一件狭义的事:网络扛住的是以 Gbps 计的洪水。真正打垮小型网站的攻击,是以每秒请求数计的,几乎不花攻击者一分钱,而且看起来完全合法。本指南划清这两者的界线,教你在一分钟内判断自己遇到的是哪一种,并讲清楚在属于你自己的那一侧,真正扛得住的办法是什么。 [阅读指南](#guide-body) [常见问题](#guide-faq) ## 本页内容 - [指南](#guide-body) - [常见问题](#guide-faq) - [相关指南](#guide-related) - [推荐页面](#guide-cta) 无需KYC 仅限加密货币 零日志 忽略 DMCA 完整Root权限 NVMe固态硬盘 20 分钟阅读 更新于 Sep 2026 本页内容 [01同一个名字,两种截然不同的攻击](#同一个名字两种截然不同的攻击) [02"含 DDoS 防护"这句话,到底买到了什么](#含-ddos-防护这句话到底买到了什么) [03第一步:先判断这到底是不是一场攻击](#第一步先判断这到底是不是一场攻击) [04直接从服务器上读懂这场攻击](#直接从服务器上读懂这场攻击) [05最初的十分钟](#最初的十分钟) [06真正扛得住的限速,以及几乎所有人都会犯的错](#真正扛得住的限速以及几乎所有人都会犯的错) [07缓存是你能部署的最廉价的防护手段](#缓存是你能部署的最廉价的防护手段) [08决定你会不会被打垮的那些上限](#决定你会不会被打垮的那些上限) [09在源站前面放点什么](#在源站前面放点什么) [10隐藏源站,比任何过滤器都更有价值](#隐藏源站比任何过滤器都更有价值) [11选好硬件和节点位置,让攻击变得无聊](#选好硬件和节点位置让攻击变得无聊) [12五件不该做的事](#五件不该做的事) [13简版结论](#简版结论) [FAQ常见问题](#guide-faq) [→推荐页面](#guide-cta) 人们真正搞懂 DDoS 缓解是怎么回事,通常要经历两个时刻。第一个时刻很平静,发生在下单付款的时候:你读到功能列表上写着"含 DDoS 防护",不假思索地以为这句话涵盖了一切。第二个时刻是在凌晨三点,网站打不开,监控图表以一种毫无道理的方式变得不对劲,而那份写进套餐里的防护——准确地说,也是按设计地——什么都没做。 这两个时刻说的其实是同一个产品和同一个事实:主机商会过滤以纯粹流量形式抵达的攻击,因为它拥有这些数据包所经过的那条管道,而你没有;它没办法过滤看起来像普通请求的攻击,因为站在网络的角度看,它们本来就是普通请求。这条界线——主机商能替你扛住的洪水,和你必须自己扛住的洪水,两者之间的界线——就是这篇指南的全部主题。接下来的内容,都是在帮你判断自己站在哪一侧,以及每一侧各自该怎么办。 ## 同一个名字,两种截然不同的攻击 "DDoS"这一个词,涵盖了两个几乎毫无共同点的问题,唯一相同的只是结果。它们要在不同的地方、由不同的人、用不同的工具来阻止,而把两者混为一谈,正是那么多防护投入落错层面的原因。 | | 流量型——三层和四层 | 应用层——七层 | | --- | --- | --- | | 会出现什么 | SYN 洪水、经开放 DNS、NTP 或 memcached 反射器发起的 UDP 放大攻击、ACK 洪水、纯粹的垃圾数据包 | 看起来正常的 HTTP 请求:GET 洪水、POST 洪水、Slowloris、用于绕过缓存的查询字符串 | | 计量单位 | Gbps,以及每秒数百万个数据包 | 每秒请求数——往往只有几千 | | 打垮你需要多少带宽 | 巨大。这是一场容量比拼 | 几乎不需要。只要接口足够昂贵,一台笔记本电脑就能做到 | | 必须在哪里被拦下 | **在上游,由你的主机商拦下。**等数据包抵达你的端口时,伤害已经造成 | **在你的服务器上,由你自己拦下**,或者在你控制的前置代理上拦下 | | 在机器上表现为 | 接口被打满,数据包计数高得离谱,CPU 却可能是空闲的 | 带宽并不起眼,但每个 worker 都在忙,负载在攀升,数据库队列在变长 | | 由谁来解决 | 主机商的流量清洗,自动完成,通常在几秒钟内 | 你自己的配置——限速、缓存、连接数上限 | 把最后两行再读一遍,因为真正实用的要点就在这里。如果接口已经被打满,不管你在服务器里敲什么命令都没用:数据包早就把端口占满了,唯一能把它们丢弃的,是拥有上游那台路由器的人。如果接口很安静但网站还是打不开,那情况正好相反——你的主机商看不出任何问题,因为站在它的角度,*确实*什么问题都没有,而修复完全是你自己的事。 流量型洪水在上游被过滤掉,因为容量在那里。能穿过那道过滤的,是看起来正常的流量——挡住它是你的工作,不是主机商的。 ## "含 DDoS 防护"这句话,到底买到了什么 网络层防护是真实存在的,也确实有价值,只是几乎总是被误读。当一家主机商宣称提供 L3/L4 过滤时,意思是它的网络会监测发往你地址的流量,一旦检测到洪水,流量就会被引导经过清洗设备,恶意部分被丢弃,看起来合法的部分则被继续转发。整个过程不需要你开工单,通常你也只会感觉到短暂的一下波动,甚至完全无感。 这一句话背后其实包含了很多内容,值得拆开来看看它到底包含什么、不包含什么: - **它覆盖的是你独自一人扛不住的攻击。**用一场 200 Gbps 的放大攻击,打一台只有 1 Gbps 端口的服务器,这不是配置问题,是纯粹的算术问题。上游清洗是唯一存在的答案。 - **它对你的应用是无状态的。**这道过滤器不知道你哪个 URL 开销大、哪些访问者已经登录,也不知道一次对搜索接口的请求,开销是请求你 logo 图片的四百倍。 - **它响应的是阈值,不是你的痛苦。**检测靠的是流量大小触发。一场从未越过阈值的攻击永远不会触发它,不管这场攻击把你的网站打垮到了什么程度。 - **在极端情况下,它可能会短暂把你的地址空路由掉。**每一张网络都有上限。如果一场攻击威胁到共享基础设施,你的地址可能会被暂时断开一段时间——这是全行业的通行做法,值得在它发生之前就了解清楚,而不是等到发生时才第一次听说。 **一句话版本:**你的主机商保护的是它自己的网络,你也因此受益。它保护不了你的应用,而且根本没有办法保护。七层不是一项被故意藏起来不卖给你的增值服务——而是一层主机商如果不终止你的 TLS,就根本看不进去的层面,而对任何选择离岸托管的人来说,终止 TLS 是一笔代价不小的交易。 ## 第一步:先判断这到底是不是一场攻击 相当一部分被怀疑是 DDoS 的事件,其实只是别的问题披了一件 DDoS 的外套,而对应的解法并不能互换。在对任何东西限速之前,先花两分钟排除这些冒牌货——这一步一旦误判,轻则搭进去一个小时,重则搭上你的真实用户。 - **你火了。**一个大型聚合站给出的链接,产生的流量形状和七层洪水一模一样,唯一的区别是来源(referrer)是真实的,请求的也是真人会想看的页面。这是一个理由让人开心的容量问题;对它限速等于自残。 - **一个爬虫没了分寸。**激进的抓取程序和 AI 训练机器人,轻轻松松就能把一台小型服务器跑垮。user-agent 通常会自己露馅,解法是 robots.txt 加上一条针对性的限制,而不是一条一刀切的通用限制。 - **是你自己搞坏了什么。**一次意外关掉了缓存的部署、一个失控的 cron 任务、一张丢了索引的数据表——这些都会表现成"负载突然飙升,原因不明"。如果时间点和你做过的某次改动对得上,那就相信那次改动。 - **洪水其实是你自己的监控系统。**这种情况少见、说出来也挺丢人,但比大家愿意承认的要常见得多。一个没有退避机制、不断重试的健康检查循环,能刷出一个货真价实、令人印象深刻的请求速率。 判断的关键问题很简单:*这些流量是不是真的想要什么东西?*真实的负载——哪怕看起来来势汹汹——是有形状的。它访问的是真实存在的页面,会跟着链接走,会加载资源文件,而且来自一个说得通的、分散在多个网络上的分布。而攻击通常懒得做这些。 ## 直接从服务器上读懂这场攻击 你不需要一个仪表盘才能判断发生了什么。依次运行四条命令,一分钟之内就能知道自己是在哪一层作战——而这个判断决定了你接下来做的每一件事。 **管道满了吗?**盯着接口计数器看。如果吞吐量被死死钉在端口上限附近,你面对的就是一场流量型攻击,你要做的是开工单,而不是改配置: - vnstat -tr 10——十秒钟的平均吞吐量,是判断是否被打满最快、最诚实的一种读数。 - 间隔一秒执行两次 cat /proc/net/dev——得到每个接口的数据包和字节增量,不需要额外工具。 **是 SYN 洪水吗?**半开连接会堆积在 SYN-RECV 状态。少数几个是正常的;几千个就不正常了: - ss -s——摘要行,一眼看到按状态分类的连接数。 - ss -tn state syn-recv | wc -l——那个真正要紧的具体数字。 **是七层吗?**如果带宽并不起眼,但一切都在变慢,那就去访问日志里数一数按客户端计算的请求数。一个地址打出几万次请求,那是业余的;十万个地址、每个只打三次,那才是真家伙: - tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30 - 把 $1 换成 $7,改为按请求路径排序。如果某一个开销很大的接口一枝独秀,你就找到了目标,同时也找到了一半的解法。 **真正耗尽的是什么?**load average 单独看意义不大。要找的是你具体撞上的那道上限:PHP-FPM 的子进程全部忙碌、数据库连接数到顶、文件描述符耗尽,或者 worker 卡在等待磁盘的 D 状态。打垮网站的是那道上限,而不是流量本身,而提高这道上限,往往比过滤任何东西都更快见效。 **排查的同时,记住这一点:**如果你运营的是一项注重隐私的服务,攻击发生的当口,恰恰是你最容易忍不住把日志级别调高、然后就再也没调回去的时候。如果必须调高,那就调高,但事后一定要调回去,并且把日志文件积极地轮转清理掉。一次让整整一个月的完整访客日志留在磁盘上的事故,等于是拿一个问题换来了一个更糟、存续更久的问题。我们的[服务器 OpSec 指南](https://servghost.com/zh/guides/server-opsec-staying-anonymous)详细讲了这方面的纪律。 ## 最初的十分钟 在压力之下,人们会本能地去拉那根看起来最大的杠杆,而那根最大的杠杆往往是错的。下面这个顺序能把损失控制到最小,大致按照又快又安全的程度排列: - **先分类,再动手。**接口被打满,说明是流量型;接口安静但 worker 都很忙,说明是七层。这里花三十秒,能省下一整个小时修错层面的功夫。 - **如果是流量型,立刻开工单,**附上目标地址、开始时间和你的接口计数器数据。然后不要再对着服务器敲命令了——这不是在服务器内部能修好的事。 - **如果是七层,先上缓存。**为匿名访问者开启激进的整页缓存,是把一次宕机变成一次无关紧要的小插曲的最快办法,而且它也是唯一一项对真实流量同样有帮助的措施。 - **然后再限速**——先限被针对的那个接口,再限其他一切。一开始就保守一点。一条把自己用户也限没了的规则,等于是自己接着攻击者继续打自己。 - **只拦截毫无疑问的目标。**十几个各自打出十万次请求的地址、一个明显是伪造的 user-agent、一个你压根没有用户的国家。压住那种想在交火当下就写一堆精巧规则的冲动;下个月你根本不会记得自己写过什么。 - **如果必须减负,那就有意识地去减。**给未登录访问者返回一个静态的"维护中"页面,能让主机保持存活、让你的 API 继续可用,还能给你争取思考时间。自己决定牺牲什么,总好过被局势替你决定。 - **把你做过的事情记下来。**每一条你临时加上的规则,都是埋给未来的你的一颗地雷。有用的规则就把它变成永久规则;其余的,明天就撤掉。 ## 真正扛得住的限速,以及几乎所有人都会犯的错 限速是应对七层的主要手段,nginx 用两条指令就能把它做好,而这两条指令解决的其实是两个真正不同的问题。limit_req 限制的是请求*速率*——一个客户端多久能问一次。limit_conn 限制的是*并发数*——一个客户端能同时占用多少个连接。洪水攻击要靠前者来防;而靠几千个近乎空闲的连接来耗尽你 worker 池的 Slowloris 攻击,要靠后者来防。只部署其中一条,你就只挡住了这个问题的一半。 三个细节,决定了一条限速规则是真的有用,还是只是摆设: - **要设置突发余量(burst),并且用上 nodelay。**真实浏览器的请求本来就是一阵一阵的——加载一个页面就会几乎同时打出十几个资源请求。一条没有余量的限速规则,会把真实访问者卡住,而一个把节奏压在阈值以下的攻击者反倒能大摇大摆地通过。 - **对开销大的接口单独限速。**你的搜索页面、登录表单、密码重置,以及任何会写入数据库的接口,理应比静态资源拿到严格得多的配额。攻击者不费吹灰之力就能找到这些接口,因为正是这些接口最伤。 - **返回 429,而不是 503。**这个状态码是在向守规矩的客户端和搜索引擎发出信号:这是限流,不是故障——它能防止一个糟糕的下午,最后又演变成一个排名问题。 **一个会悄无声息让上面这一切全部作废的错误:**只要你的服务器前面挂着任何东西——CDN、负载均衡器,或者你自己的反向代理——那么每一个请求抵达时,用的都是*它*的地址,而不是访问者的地址。这时按客户端计算的限速,算的其实是把整个互联网当成了一个客户端,结果要么完全不起作用,要么把你的全部访客一次性封光。你必须*先*配置好真实 IP 来源(在 nginx 里,给代理的地址段配置 set_real_ip_from,再给它发送的头部字段配置 real_ip_header),这些限速规则才谈得上有意义。而且这份信任也必须只限于代理自己的地址段:如果信任一个来自公网、由客户端自行提供的头部字段,攻击者就能在每个请求里伪造一个新身份,直接穿过你设下的所有限制。 ## 缓存是你能部署的最廉价的防护手段 限速拒绝的是工作。缓存则让工作根本不存在。对匿名访问者能看到的任何内容,整页缓存都会改变整场攻击的经济账:一个原本要花一次数据库往返、一次模板渲染和一个 PHP worker 才能完成的请求,变成了一次以微秒计的文件读取。同一台在每秒四百个动态请求下就已经瘫痪的服务器,能在毫无压力的情况下,应对每秒几万次的缓存命中。 真到要动真格开启缓存的时候,以下几点才是关键: - **只为匿名访问者做缓存。**遇到会话 cookie 就绕过缓存。把一个登录用户的页面发给另一个用户看,是比你正在修的这场宕机严重得多的事故。 - **有意地返回过期内容(stale)。**nginx 的 proxy_cache_use_stale 配合 updating error timeout,意味着后端吃力的时候,访问者拿到的是一个稍微过期的页面,而不是一个错误页。在攻击期间,这就是一个看起来正常的网站,和一个看起来已经挂了的网站之间的区别。 - **合并重复的缓存未命中。**proxy_cache_lock 能保证一千个同时请求同一个尚未缓存页面的请求,最终只产生一次到后端的请求,而不是一千次。少了它,一次绕过缓存的攻击会直接穿过缓存,全力砸在你的数据库上。 - **拆掉用于绕过缓存的查询字符串这一招。**常见手法是在后面附上一个 ? 和一个随机值,让每个请求都成为独一无二的缓存键,永远命中不了缓存。把你的缓存键规范化,忽略掉那些应用实际上根本不会用到的查询参数。 这里有一种值得记在心里的令人愉快的不对称:你花在缓存上的每一个小时,同时也会让网站在风平浪静的日子里更快、运行成本更低、更扛得住突然爆红。几乎没有别的哪一道防线,能在什么坏事都没发生的时候也带来回报。 ## 决定你会不会被打垮的那些上限 大多数服务器倒下,不是因为 CPU 用光了。它们倒下,是因为撞上了一道没有人刻意设置过的隐形上限——一个十年前定下的默认值,在早就没人再用的硬件上曾经合理过。真正在攻击中最先崩溃的,是下面这些: - **应用 worker。**PHP-FPM 的 pm.max_children、你的 Python worker 数量、你的 Node 集群规模——这才是你网站真正的并发上限。一旦全部忙碌,每多来一个访问者都要排队,而不管 CPU 看起来多闲,网站都已经等同于宕机。把这个数值提高到内存允许的极限为止——发生 swap 比排队还要糟糕。 - **accept 队列。**net.core.somaxconn 和你的监听队列(backlog)长度,决定了有多少个连接可以排队等待被接受。一个过小的 backlog,会把一次本来扛得住的突发流量,变成一堆被拒绝的连接。 - **SYN cookies。**net.ipv4.tcp_syncookies 能让内核应对 SYN 洪水时,不必为那些永远不会建立完成的连接分配状态。现代内核默认会启用它;去确认一下,而不是想当然地认为它已经开着——这项检查不花你一分钱,却能让你躲开最常见的一种洪水攻击。 - **文件描述符。**每一个连接都是一个描述符。默认的 nofile 限制,常常低于你实际要处理的连接数,而它的失败方式——accept 不断失败,但表面上一切正常——在凌晨三点真的会把人搞糊涂。 - **数据库连接。**只提高 worker 数量而不提高连接池大小,只是把排队现象挪到了一个更难看见的地方。这两个数字必须一起调整。 把这些参数调好要趁风平浪静的日子,而不是等到事故发生时。了解它们的意义在于,网站一旦倒下,你能直接说出它撞上了哪一道上限,而不是靠猜——而一道能被说出名字的上限,就是一道能被修好的上限。 ## 在源站前面放点什么 以上这些都发生在服务器本身上。下一步要决定的是,这台服务器究竟要不要直接承接流量。老老实实说,一共有三种选择,而正确答案取决于你托管的是什么,远胜于取决于你的预算。 | 方案 | 它给你带来什么 | 它让你付出什么 | | --- | --- | --- | | 源站直接暴露,做好加固 | 简单,没有第三方,TLS 终止完全掌握在自己手里 | 你的地址是公开且永久的。七层完全靠你自己扛 | | 商业 CDN 或清洗服务 | 巨大的吸纳能力,一键开启的验证页面,全球范围的缓存 | 一个对你的内容有自己看法的投诉窗口,以及一家能看到你流量的公司。对离岸项目或涉及 DMCA 敏感内容的项目来说,这可能是整套精心配置里最薄弱的一环 | | 自己的前置节点——一台运行 nginx、代理流量到已用防火墙锁死的源站的小型 VPS | 完全的控制权,请求路径中没有第三方,一个可以随时烧掉重换的地址,以及一个始终藏在幕后的真实地址 | 它自己也有容量上限,还多了一台要维护的机器。在不同网络里部署两三个前置节点,能让攻击者明显更难把你打垮 | 自建前置节点这个方案,应得的关注通常比它实际得到的要多,对那些选择离岸托管的理由未必会得到大型 CDN 认同的人来说尤其如此。这套模式并不光鲜:前面是几个便宜的代理节点,源站用防火墙锁死、只接受这些节点发来的连接,DNS 指向这些前置节点。一旦某个前置节点被攻击,几分钟内就能换上一个新地址,源站完全不会察觉。这套架构的完整版本——包括源站地址依然会泄露的六种方式——是我们[隐藏源站 IP](https://servghost.com/zh/guides/hiding-your-origin-server-ip)这篇指南的主题。 ## 隐藏源站,比任何过滤器都更有价值 这一点值得直白地说出来,因为它颠倒了通常的优先级:对你来说,成本最低的 DDoS 缓解手段,是一个攻击者根本拿不到的地址。过滤,是在这一点已经失守之后才要做的事。 这一点的分量比听起来要重得多,因为源站地址一直在悄悄泄露。你把代理接上之前留下的历史 DNS 记录,会比这次变更多存活好几年。应用直接发出的邮件,邮件头里就带着这个地址。为裸地址签发的 TLS 证书,会被永久发布在证书透明度日志里。一个错误页面、一次重定向,或者一个从未被代理过的冷门子域名,都会把它暴露出来。如果你是给一台曾经直接暴露过的服务器,事后才在前面接上 CDN,那就应该假定旧地址已经泄露,除非你已经把它换掉。 **由此推出的一条防火墙规则,是这篇指南里单条价值最高的一行:**一旦前面有东西在挡着,源站就应该在 80 和 443 端口上,拒绝除了前端地址之外的一切连接。没有这条规则,代理就只是一个建议——任何人只要得知真实地址,就能绕开代理直接攻击你,而你在前端配置的一切都成了摆设。 ## 选好硬件和节点位置,让攻击变得无聊 这里面有一部分,是在攻击发生之前、在你选套餐的那一刻就已经决定了的。有三项属性,比配置表上看起来的更重要: - **不限流量带宽。**在按流量计费的套餐上,一场攻击带来的不只是宕机,还有一张账单。那些你从未招惹、也无法拒绝的流量,依然会计入你的流量配额。不限流量带宽能把一个财务风险,变成一个纯粹的技术问题,而技术问题是好应付得多的一类问题。 - **端口是不是完全属于你。**在共享的虚拟化主机上,邻居遭到攻击也会拖累你,而且你自己能拿到的防护上限,也是和别人共享的。拥有独立端口的[独立硬件](https://servghost.com/zh/dedicated),能同时消除这两种影响。对一个预计会招来恶意关注的项目来说,这是从 [VPS](https://servghost.com/zh/vps) 升级上去最充分的理由——比核心数或内存都更充分。 - **网络位于哪里。**一张拥有真实中转容量、对等互联(peering)充分的欧洲网络,扛得住的洪水规模,是一张对等互联薄弱的网络望尘莫及的,而你出于法律原因选中的司法辖区,同样有自己的网络特性。在从可选的[节点位置](https://servghost.com/zh/locations)中挑选时,这两点都值得确认。 还有一个关于规模的论点,不动声色地站在简单这一边。一个放在普通服务器上、有缓存挡在前面的静态网站,极难被打垮;而同样的内容如果放在一套笨重的 CMS 上,搜索接口又没做缓存,一个有决心的人靠一个脚本就能把它打垮。减少动态的部分,本身就是一种防护手段,而且是免费的。如果你的项目确实长期处于高负载之下,我们关于[高流量托管](https://servghost.com/zh/use-cases/high-traffic-hosting)的说明,讲的正是同一个问题里选型这一面。 ## 五件不该做的事 这里的失败模式很有规律,规律到值得列出来,而每一条都曾经让某个人搭进去一个周末: - **不要自己把自己的地址空路由掉。**把自己的地址拉进黑洞,是让攻击终止的最字面意义上的一种办法——没有人能连到你,包括你的用户在内。这是主机商才会用的最后手段,不是你该主动采取的行动。 - **不要把 fail2ban 当成 DDoS 防护。**面对来自少数几个地址的暴力破解尝试,它是个称手的工具。但面对一场分布式洪水,它要花几分钟才能反应过来,而洪水几秒钟就到了,而且一条封禁了几千个地址的规则,在防火墙处理上消耗的资源,可能比这场攻击本身造成的损失还大。 - **不要付赎金。**绝大多数扬言要发动毁灭性攻击的勒索邮件,来自那些根本没有能力动手、只是群发几千封一模一样邮件的人。而那一小撮真有能力兑现威胁的人,会再来一次,因为你已经证明了自己会付钱。 - **不要报复回去。**这么做在几乎所有地方都是违法的,而且攻击流量的来源,本身就是被攻陷的第三方。你打的其实是受害者,而且是用一个明明白白属于你自己的地址去打。 - **不要在恐慌中迁移。**在攻击进行中换主机,意味着新地址几分钟内就会公开,而且你手头没有任何调好的配置。先稳住局面,以后再从容地迁移——如果你确实要迁移,我们那篇关于[不停机迁移](https://servghost.com/zh/guides/migrate-website-to-offshore-hosting)的指南存在的意义,正是让这次迁移本身不至于变成第二场事故。 ## 简版结论 把推理过程去掉,可执行的模型可以压缩成八行: - **先分类。**接口被打满,说明是流量型,归你的主机商管。接口安静但 worker 已经耗尽,说明是七层,归你自己管。 - **流量型就开工单,**附上地址、时间戳和你的计数器数据——然后不要再碰服务器了。 - **为匿名访问者激进地开启缓存,**承压时返回过期内容,并合并重复的缓存未命中。这是你能做的杠杆效应最大的一项改动。 - **同时按请求速率和并发数限速,**对开销最大的接口收得最紧,并返回 429。 - **在做以上任何一件事之前,先修好你的真实 IP 配置,**否则代理背后的每一条按客户端限速规则,要么形同虚设,要么后果灾难性。 - **了解你的各项上限**——worker、backlog、描述符、数据库连接——并且趁风平浪静的日子,有意识地把它们提高。 - **让源站地址保密,并用防火墙锁死,**只放行你的前置节点。这一条比所有过滤器加起来都更有价值。 - **购买不限流量带宽,**这样你没招惹过的流量,就永远不会同时变成一张账单。 以上这些都不会让你彻底免疫,而任何声称能卖给你免疫力的人,卖的其实是别的东西。它们真正做到的,是把你从一个无聊的青少年就能轻易打下线的那群人里挪出来,挪进一个必须动用真正的资源、怀着真正的意图才能打扰到的那群人里——而对绝大多数项目来说,这已经和绝对安全没有区别了。剩下的,就是那些让一台服务器在其他方方面面同样出色的、并不光鲜的日常功夫:[从第一天起就加固到位](https://servghost.com/zh/guides/first-hour-vps-hardening-checklist),[在最糟的一天也能恢复如初](https://servghost.com/zh/guides/vps-backup-strategy),并且把它放在一个把你的流量当成你自己的事的地方运行。 常见问题 ## 小型服务器上的 DDoS——常见问题 ### 01 "含 DDoS 防护"是不是就意味着我什么都不用担心了? 不是,而且这个缺口是精确的,不是笼统的。套餐自带的防护是网络层过滤:它会在流量型洪水——SYN 洪水、UDP 放大攻击、原始垃圾包风暴——到达你的端口之前,就在上游把它们丢弃。这正是你自己完全无力应对的那一类攻击,所以把它包含在套餐里是对的。但它不会检查你的应用,所以一次针对昂贵接口、每秒几千请求的 HTTP 洪水会原封不动地穿过它,把你的网站打垮,而与此同时所有网络图表看起来都很正常。七层是你自己要负责的配置:缓存、限速和连接数上限。 ### 02 我要怎么分辨这是 DDoS 攻击还是正常的流量高峰? 问一句:这些流量是不是真的想要什么东西。真实访问者,哪怕是因为一个热门链接而突然暴涨的那种,请求的都是真实存在的页面,会加载页面上的资源,带着说得通的来源(referrer),而且分布在许多不同网络上,呈现出自然的样子。攻击通常只会猛攻一个路径,不理会资源文件,user-agent 要么说不通要么干脆没有,分布看起来一眼就很人造。查一下访问日志里按客户端地址和按路径统计的请求数:如果某一个接口一家独大、其他什么都没人加载,那就是攻击。如果被请求的都是一个真人会想看的页面,来源也是真实的,那你遇到的只是一个理由让人高兴的容量问题。 ### 03 受到攻击时,我能做的最有效的一件事是什么? 为匿名访问者开启整页缓存,并配置成后端吃力时改为返回稍微过期的内容(stale)。限速拒绝的是要不要做这份工作;缓存则让这份工作根本不需要发生。一个原本要花一次数据库查询、一次模板渲染和一个应用 worker 才能完成的请求,变成了一次文件读取,同一台在每秒几百个动态请求下就已经瘫痪的硬件,能够轻松应对每秒几万次的缓存命中。它也是这份清单里唯一一项对真实流量同样有帮助的措施,所以和限速不同,它不会反过来伤到你自己的用户。 ### 04 为什么我在前面接入 CDN 之后,nginx 的限速就失效了? 因为现在每一个请求都是从 CDN 的地址而不是访问者的地址抵达的,所以按客户端计算的限速,实际上是把整个互联网都算成了同一个客户端。根据阈值设置不同,它要么永远不会触发,要么会一次性封掉你的全部流量。配置好你的真实 IP 来源——在 nginx 里,也就是可信代理的地址段,加上代理发送的那个头部字段——让限速重新按真正的访问者来计算。这份信任必须只限于代理自己的地址段:如果接受来自公网、由客户端自行提供的头部字段,攻击者就能在每一次请求里伪造一个新身份,直接穿过你设下的所有限制。 ### 05 fail2ban 足以挡住一次 DDoS 攻击吗? 不够。fail2ban 是按固定间隔读取日志,超过阈值才封禁地址,这适合应对来自少数几个来源的暴力破解尝试。而一次分布式攻击,是在几秒钟内从成千上万个地址涌来,每个地址只发几个请求,阈值根本不会被触发,反应速度无论如何也跟不上。更糟的是,一份膨胀到几万条的规则集,消耗的资源可能比攻击本身还多。把 fail2ban 留给 SSH 和登录接口用,洪水攻击要靠缓存、限速和上游过滤来处理。 ### 06 我应该用 CDN,还是自己在前面跑一个反向代理? 这取决于你托管的是什么内容,而不是取决于预算。商业 CDN 能带来你自己无法企及的吸纳能力,以及一键开启的验证页面,但你也因此继承了它的投诉窗口,而且它能看到你的流量——对离岸项目或涉及 DMCA 敏感内容的项目来说,这往往是整套精心配置里最薄弱的一环。自己搭建前置节点要多花不少功夫,容量也确实有上限,但请求路径中没有第三方,而且一旦前端遭到攻击,几分钟内就能换一个新地址顶上。不管选哪一种,源站都必须用防火墙锁死,只允许来自前端的 Web 流量,否则整套安排都只是摆设。 ### 07 一次攻击除了让网站下线,还会让我多花钱吗? 如果是按流量计费的套餐,会的——那些你从未招惹、也无法拒绝的流量,依然会计入你的流量配额,一场持续的洪水攻击产生的超额账单,甚至可能超过一整年的主机费用。这就是不限流量带宽的实际意义所在:它在配置表上看起来只是个小细节,实际上却能把一个财务风险变成一个纯技术问题。还有一点最好提前知道:如果攻击威胁到共享基础设施,主机商可能会暂时把这个地址空路由掉;这是全行业的通行做法,不代表你选的这家主机商有什么问题。 ### 08 换成离岸或者无需 KYC 的主机商,会让攻击更容易找上门吗? 主机商的选择本身是中立的,真正招惹攻击的是你运行的内容。游戏服务器、论坛、流媒体、交易市场,以及任何有竞争对手或结怨对象的项目,不管放在哪个司法辖区都会招来攻击。离岸真正改变的,是你的处境:你不太可能因为显得麻烦而被主机商直接下线,但这也是一把双刃剑——你得到的保障是技术上的,而不是合同上的。选一个真正有传输容量的节点位置,选不限流量带宽,把源站地址藏好,并且从第一天起就把七层攻击当成自己的责任,而不是等出了事才想起来。 相关指南 ## 继续阅读 [### 2026 年如何选择离岸托管司法管辖区 购买前 选择离岸司法管辖区的实用决策框架：数据留存法规、MLAT 风险敞口、DMCA 立场、司法效率与现实执法力度——逐国深度分析。 6 个常见问题](https://servghost.com/zh/guides/choosing-an-offshore-jurisdiction) [### VPS 与独立服务器：哪种更适合隐私敏感工作负载 购买前 何时 VPS 已经足够，何时共享租用是一种风险，何时裸金属才是唯一诚实的答案。硬件隔离、虚拟机监控程序风险，以及成本与威胁模型的匹配。 6 个常见问题](https://servghost.com/zh/guides/vps-vs-dedicated-for-privacy) [### 无 KYC VPS 上的自托管 VPN：WireGuard 与 OpenVPN 运营管理 为什么自托管 VPN 优于商业服务商，以及 WireGuard 和 OpenVPN 在 2026 年隐私、性能和运营风险方面的真实对比。 6 个常见问题](https://servghost.com/zh/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090对比H100 SXM5用于AI推理（及RTX 5090的定位） 购买前 购买决策指南：2026年自托管LLM、图像、视频、语音和微调工作负载选择哪款NVIDIA GPU。RTX 4090 vs RTX 5090 vs H100 SXM5 vs 双H100——显存、吞吐量、每token价格，以及各自的胜出场景。 6 个常见问题](https://servghost.com/zh/guides/rtx-4090-vs-h100-for-ai-inference) [### 面向MT4 / MT5 / cTrader外汇交易的离岸Windows RDP 运营管理 完整指南：为何使用Windows RDP进行外汇交易、如何选择低延迟离岸司法管辖区、MT4 / MT5 / cTrader / Expert Advisor设置、到经纪商服务器的延迟，以及免KYC结账路径。 6 个常见问题](https://servghost.com/zh/guides/offshore-windows-rdp-for-forex-trading) [### DMCA豁免托管详解：2026年的真实含义 购买前 "DMCA豁免"托管究竟能给你什么保障、哪些司法管辖区真正背书、哪类业务确实需要它——以及你必须了解的陷阱。 6 个常见问题](https://servghost.com/zh/guides/dmca-ignored-hosting-explained) [### 加密货币匿名域名注册：2026年WHOIS隐私完全指南 隐私与支付 2026年实用指南：如何注册域名而不暴露身份——各TLD的WHOIS制度、注册商选择、代币支付方案，以及真正能在压力下成立的匿名堆栈。 6 个常见问题](https://servghost.com/zh/guides/anonymous-domain-registration-with-crypto) [### 托管加密支付：Monero、Bitcoin 与 USDT 对比 隐私与支付 支付币种如何影响主机对你的了解程度。XMR、BTC 和 USDT 的隐私性、手续费、确认终局性和链上分析风险敞口——附清晰推荐。 6 个常见问题](https://servghost.com/zh/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### 离岸主机真的匿名吗?诚实的答案 隐私与支付 离岸、无KYC主机去除了普通主机商收集的身份信息,但"匿名"与否还取决于支付方式、服务商的日志政策,以及您自身的操作安全(opsec)。以下是真正可被追踪的内容。 6 个常见问题](https://servghost.com/zh/guides/is-offshore-hosting-truly-anonymous) [### VPS加固的第一个小时:清单 运营管理 一份具体、按顺序排列的清单,帮您在一小时内加固一台新VPS:SSH密钥、防火墙、fail2ban、自动更新,以及能阻止大多数机会主义攻击的攻击面缩减措施。 6 个常见问题](https://servghost.com/zh/guides/first-hour-vps-hardening-checklist) [### 什么是 No-KYC 主机托管？定义、合法性与运作方式 隐私与支付 No-KYC 主机托管让您无需任何身份验证即可租用服务器——无需姓名、邮箱或证件。以下是其确切含义、技术原理、合法性说明，以及如何甄别真正的 No-KYC 服务商。 6 个常见问题](https://servghost.com/zh/guides/what-is-no-kyc-hosting) [### 境外托管合法吗？2026年的诚实解答 购买前 境外托管对您和服务提供商而言都是合法的。本文将解释这一术语的真正含义、法律边界究竟在哪里、值得摒弃的误区，以及如何负责任地使用境外托管。 6 个常见问题](https://servghost.com/zh/guides/is-offshore-hosting-legal) [### 如何使用 Monero（XMR）支付主机费用——分步指南 隐私与支付 使用 Monero（XMR）支付 VPS 或独立服务器费用的分步指南：为什么 XMR 是隐私性最强的支付方式、如何获取 XMR，以及从生成账单到服务器上线的完整结账流程。 6 个常见问题](https://servghost.com/zh/guides/how-to-pay-for-hosting-with-monero) [### 如何匿名托管网站——2026年实用指南 隐私与支付 一份系统、分层的实用指南，教你如何在不暴露任何身份信息的前提下托管网站——涵盖账户注册、支付方式、域名选择、司法管辖、连接安全与内容管理，每一层逐一详解。 6 个常见问题](https://servghost.com/zh/guides/how-to-host-a-website-anonymously) [### 如何在 VPS 上搭建 WireGuard VPN — 分步指南 运营管理 使用 WireGuard 在 VPS 上构建私有 VPN：为何自托管 VPN 优于商业服务、从安装到客户端连接的完整配置流程，以及安全加固方法。 6 个常见问题](https://servghost.com/zh/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### 如何在 GPU 服务器上自托管 LLM — 2026 年完整指南 运营管理 在租用的 GPU 服务器上运行自己的大语言模型：为何自托管优于 API 调用、如何选择 GPU 与模型、使用 Ollama 或 vLLM 的部署方式，以及实际成本分析。 6 个常见问题](https://servghost.com/zh/guides/self-host-an-llm-on-a-gpu-server) [### 防弹主机与离岸主机——两者有何区别？ 购买前 防弹主机与离岸主机常被混为一谈，但两者截然不同。本文厘清真正的区别、说明其重要性，并指出你实际需要的是哪一种。 6 个常见问题](https://servghost.com/zh/guides/bulletproof-vs-offshore-hosting) [### 如何用 Bitcoin 购买 VPS — 分步详解（2026） 购买前 面向初学者的 Bitcoin 购买 VPS 全流程指南：获取 BTC、选择套餐、支付账单，以及你将得到什么——一台无需绑卡、无需实名的运行中服务器。 6 个常见问题](https://servghost.com/zh/guides/how-to-buy-a-vps-with-bitcoin) [### 2026年最佳DMCA忽略托管国家 购买前 当您需要将服务器部署在美国式版权投诉难以触及的地方时，该如何选择：哪些司法管辖区真正有效，DMCA忽略托管究竟意味着什么，以及如何做出明智的选择。 6 个常见问题](https://servghost.com/zh/guides/best-countries-for-dmca-ignored-hosting) [### 如何托管 Tor 隐藏服务（.onion 站点）—— 2026 年完整指南 运营管理 在 VPS 上搭建 Tor 洋葱服务：了解隐藏服务的概念、为何它是匿名托管的最强形式、完整配置流程，以及如何保持真正的匿名性。 6 个常见问题](https://servghost.com/zh/guides/how-to-host-a-tor-hidden-service) [### 离岸邮件服务器搭建指南——2026年如何自托管私人电子邮件 运营管理 在离岸 VPS 上搭建属于自己的私人邮件服务器：为什么要自托管电子邮件、所需条件、使用一体化邮件系统的实际搭建流程，以及如何保证邮件送达率。 6 个常见问题](https://servghost.com/zh/guides/offshore-mail-server-setup) [### 加密货币节点托管指南 — 在 VPS 上运行区块链节点 运营管理 如何在服务器上托管区块链节点：为何要运行自己的节点、如何为 Bitcoin、Ethereum、Monero 等链配置服务器规格、部署流程，以及如何保护节点隐私。 6 个常见问题](https://servghost.com/zh/guides/crypto-node-hosting-guide) [### Stable Diffusion GPU托管 — 运行您自己的图像服务器 运营管理 在您自己的GPU服务器上运行Stable Diffusion：为何选择自托管图像生成、如何挑选GPU、配合Web界面的部署方法，以及与托管服务的费用对比。 6 个常见问题](https://servghost.com/zh/guides/gpu-hosting-for-stable-diffusion) [### 服务器 OpSec — 运营匿名服务器时保持匿名 隐私与支付 为运营匿名服务器的用户提供的操作安全指南：揭露身份的常见错误、预防这些错误的习惯，以及如何将真实身份与匿名活动彻底隔离。 6 个常见问题](https://servghost.com/zh/guides/server-opsec-staying-anonymous) [### Seedbox 搭建指南——2026年打造您的专属私人 Seedbox 运营管理 如何在服务器上搭建自己的 seedbox：什么是 seedbox、如何选配硬件、安装带有 Web 界面的 BitTorrent 客户端，以及如何保障私密性与安全性。 6 个常见问题](https://servghost.com/zh/guides/seedbox-setup-guide) [### 如何用自己的 VPS 绕过 DPI 审查(2026 指南) 隐私与支付 VPN 突然失灵?如何用自己的 VPS 绕过 DPI 审查:深度包检测(DPI)究竟能识别出什么、2026 年仍然有效的五种协议各自能突破哪类封锁,以及一份完整的 VLESS+REALITY 部署演示。 6 个常见问题](https://servghost.com/zh/guides/bypass-dpi-censorship-with-your-own-vps) [### VPS 全盘加密:LUKS 配置与它真正能防住什么 运营管理 如何用 LUKS 给 VPS 加密:日常数据适用的加密数据卷、配合 dropbear 远程解锁的全盘 root 加密,或安装时整机加密的裸机服务器,三种方案怎么选;小型 VPS 上 Argon2id 内存参数为何会让解锁失败;以及磁盘加密到底能防住哪些威胁、又对哪些威胁完全无效的坦率说明。 8 个常见问题](https://servghost.com/zh/guides/full-disk-encryption-on-a-vps) [### 隐藏源站 IP:CDN、反向代理与仍会泄露的部分 隐私与支付 要不要在离岸服务器前面挂一个 CDN,是买下服务器后最先冒出来的问题:它到底能隐藏什么、你会因此继承来一个什么样的投诉窗口、源站 IP 依然会泄露的六种常见方式、如何锁死源站只让前端可达,以及如何用十分钟自查你自己的服务器有没有已经暴露。 8 个常见问题](https://servghost.com/zh/guides/hiding-your-origin-server-ip) [### VPS备份完全指南:加密、异地存储与恢复测试 运营管理 主机不提供任何备份,终止后24小时内数据即被清除。看清哪些操作真正会毁掉服务器、快照为何不是备份、restic与Borg怎么选,以及如何验证备份真能恢复。 8 个常见问题](https://servghost.com/zh/guides/vps-backup-strategy) [### 自建 Matrix 服务器：联邦、元数据与端到端加密盲区 运营管理 自建 Matrix 服务器到底改变了什么：Synapse 与 Conduit 怎么选、永远无法更改的 server_name、吃满硬盘的媒体缓存，以及联邦协议依然会暴露哪些信息。 8 个常见问题](https://servghost.com/zh/guides/self-host-a-matrix-server) [### 网站迁移离岸主机指南:零停机切换与痕迹清理 运营管理 让主机迁移变得平淡无奇的顺序:提前几天调低DNS TTL、新旧服务器并行运行、把写入冻结控制在几分钟而不是几小时——外加清理这次搬迁留下的被动DNS、Certificate Transparency和WHOIS痕迹。 8 个常见问题](https://servghost.com/zh/guides/migrate-website-to-offshore-hosting) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server 运营管理 Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. 8 个常见问题](https://servghost.com/zh/guides/self-host-a-crypto-payment-gateway) ## 把它放在能替你过滤洪水的地方 七个司法辖区的离岸 KVM 服务器,自带 L3/L4 DDoS 过滤、不限流量带宽、完整 root 权限与 NVMe 存储。无需 KYC,仅收加密货币,交易确认后几分钟内即可部署完成。 [查看VPS方案](https://servghost.com/zh/vps) [独立服务器](https://servghost.com/zh/dedicated) [离岸托管](https://servghost.com/zh/offshore-hosting) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servghost.com/#organization", "name": "ServGhost", "url": "https://servghost.com", "description": "7 个隐私友好司法管辖区的离岸 VPS 和独立服务器。无KYC、无日志、仅加密货币支付。隐私即架构。", "logo": { "@type": "ImageObject", "url": "https://servghost.com/ServGhost.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servghost.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servghost.com/canary", "https://servghost.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servghost.com/#website", "url": "https://servghost.com", "name": "ServGhost", "publisher": { "@id": "https://servghost.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "VPS DDoS 防护指南:主机止步之处,七层攻击的起点", "description": "主机商过滤数据包洪水,请求洪水则要靠你自己。L3/L4 清洗如何运作、为什么七层攻击能直接穿透它,以及让离岸小型服务器在被攻击时依然在线的缓存、限速与连接数上限。", "image": "https://servghost.com/assets/img/guides/surviving-a-ddos-attack-on-your-vps.webp?v=1788769011", "author": { "@type": "Organization", "@id": "https://servghost.com/#editorial", "name": "ServGhost Editorial", "url": "https://servghost.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servghost.com/#organization" } }, "publisher": { "@id": "https://servghost.com/#organization" }, "datePublished": "2026-09-07T00:00:00+00:00", "dateModified": "2026-09-07T00:00:00+00:00", "mainEntityOfPage": "https://servghost.com/guides/surviving-a-ddos-attack-on-your-vps", "inLanguage": "zh", "keywords": "VPS DDoS 防护, 服务器被 DDoS 攻击怎么办, nginx 防 CC 攻击, 七层 DDoS 攻击怎么防, 离岸高防服务器, L3 L4 DDoS 过滤, SYN flood 攻击防御, 隐藏源站 IP 防 DDoS", "articleSection": "运营管理", "wordCount": 3993 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "\"含 DDoS 防护\"是不是就意味着我什么都不用担心了?", "acceptedAnswer": { "@type": "Answer", "text": "不是,而且这个缺口是精确的,不是笼统的。套餐自带的防护是网络层过滤:它会在流量型洪水——SYN 洪水、UDP 放大攻击、原始垃圾包风暴——到达你的端口之前,就在上游把它们丢弃。这正是你自己完全无力应对的那一类攻击,所以把它包含在套餐里是对的。但它不会检查你的应用,所以一次针对昂贵接口、每秒几千请求的 HTTP 洪水会原封不动地穿过它,把你的网站打垮,而与此同时所有网络图表看起来都很正常。七层是你自己要负责的配置:缓存、限速和连接数上限。" } }, { "@type": "Question", "name": "我要怎么分辨这是 DDoS 攻击还是正常的流量高峰?", "acceptedAnswer": { "@type": "Answer", "text": "问一句:这些流量是不是真的想要什么东西。真实访问者,哪怕是因为一个热门链接而突然暴涨的那种,请求的都是真实存在的页面,会加载页面上的资源,带着说得通的来源(referrer),而且分布在许多不同网络上,呈现出自然的样子。攻击通常只会猛攻一个路径,不理会资源文件,user-agent 要么说不通要么干脆没有,分布看起来一眼就很人造。查一下访问日志里按客户端地址和按路径统计的请求数:如果某一个接口一家独大、其他什么都没人加载,那就是攻击。如果被请求的都是一个真人会想看的页面,来源也是真实的,那你遇到的只是一个理由让人高兴的容量问题。" } }, { "@type": "Question", "name": "受到攻击时,我能做的最有效的一件事是什么?", "acceptedAnswer": { "@type": "Answer", "text": "为匿名访问者开启整页缓存,并配置成后端吃力时改为返回稍微过期的内容(stale)。限速拒绝的是要不要做这份工作;缓存则让这份工作根本不需要发生。一个原本要花一次数据库查询、一次模板渲染和一个应用 worker 才能完成的请求,变成了一次文件读取,同一台在每秒几百个动态请求下就已经瘫痪的硬件,能够轻松应对每秒几万次的缓存命中。它也是这份清单里唯一一项对真实流量同样有帮助的措施,所以和限速不同,它不会反过来伤到你自己的用户。" } }, { "@type": "Question", "name": "为什么我在前面接入 CDN 之后,nginx 的限速就失效了?", "acceptedAnswer": { "@type": "Answer", "text": "因为现在每一个请求都是从 CDN 的地址而不是访问者的地址抵达的,所以按客户端计算的限速,实际上是把整个互联网都算成了同一个客户端。根据阈值设置不同,它要么永远不会触发,要么会一次性封掉你的全部流量。配置好你的真实 IP 来源——在 nginx 里,也就是可信代理的地址段,加上代理发送的那个头部字段——让限速重新按真正的访问者来计算。这份信任必须只限于代理自己的地址段:如果接受来自公网、由客户端自行提供的头部字段,攻击者就能在每一次请求里伪造一个新身份,直接穿过你设下的所有限制。" } }, { "@type": "Question", "name": "fail2ban 足以挡住一次 DDoS 攻击吗?", "acceptedAnswer": { "@type": "Answer", "text": "不够。fail2ban 是按固定间隔读取日志,超过阈值才封禁地址,这适合应对来自少数几个来源的暴力破解尝试。而一次分布式攻击,是在几秒钟内从成千上万个地址涌来,每个地址只发几个请求,阈值根本不会被触发,反应速度无论如何也跟不上。更糟的是,一份膨胀到几万条的规则集,消耗的资源可能比攻击本身还多。把 fail2ban 留给 SSH 和登录接口用,洪水攻击要靠缓存、限速和上游过滤来处理。" } }, { "@type": "Question", "name": "我应该用 CDN,还是自己在前面跑一个反向代理?", "acceptedAnswer": { "@type": "Answer", "text": "这取决于你托管的是什么内容,而不是取决于预算。商业 CDN 能带来你自己无法企及的吸纳能力,以及一键开启的验证页面,但你也因此继承了它的投诉窗口,而且它能看到你的流量——对离岸项目或涉及 DMCA 敏感内容的项目来说,这往往是整套精心配置里最薄弱的一环。自己搭建前置节点要多花不少功夫,容量也确实有上限,但请求路径中没有第三方,而且一旦前端遭到攻击,几分钟内就能换一个新地址顶上。不管选哪一种,源站都必须用防火墙锁死,只允许来自前端的 Web 流量,否则整套安排都只是摆设。" } }, { "@type": "Question", "name": "一次攻击除了让网站下线,还会让我多花钱吗?", "acceptedAnswer": { "@type": "Answer", "text": "如果是按流量计费的套餐,会的——那些你从未招惹、也无法拒绝的流量,依然会计入你的流量配额,一场持续的洪水攻击产生的超额账单,甚至可能超过一整年的主机费用。这就是不限流量带宽的实际意义所在:它在配置表上看起来只是个小细节,实际上却能把一个财务风险变成一个纯技术问题。还有一点最好提前知道:如果攻击威胁到共享基础设施,主机商可能会暂时把这个地址空路由掉;这是全行业的通行做法,不代表你选的这家主机商有什么问题。" } }, { "@type": "Question", "name": "换成离岸或者无需 KYC 的主机商,会让攻击更容易找上门吗?", "acceptedAnswer": { "@type": "Answer", "text": "主机商的选择本身是中立的,真正招惹攻击的是你运行的内容。游戏服务器、论坛、流媒体、交易市场,以及任何有竞争对手或结怨对象的项目,不管放在哪个司法辖区都会招来攻击。离岸真正改变的,是你的处境:你不太可能因为显得麻烦而被主机商直接下线,但这也是一把双刃剑——你得到的保障是技术上的,而不是合同上的。选一个真正有传输容量的节点位置,选不限流量带宽,把源站地址藏好,并且从第一天起就把七层攻击当成自己的责任,而不是等出了事才想起来。" } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "首页", "item": "https://servghost.com/zh/" }, { "@type": "ListItem", "position": 2, "name": "隐私托管指南", "item": "https://servghost.com/zh/guides" }, { "@type": "ListItem", "position": 3, "name": "VPS DDoS 防护指南:主机止步之处,七层攻击的起点", "item": "https://servghost.com/zh/guides/surviving-a-ddos-attack-on-your-vps" } ] } ```