被 DDoS攻击打到一定程度，第一个「投降」的往往不是你的服务器，而是机房：带宽被跑满、出口异常、同机房客户投诉，机房会限速、封端口，甚至直接强制下架。本文用 9 个问答讲清机房的停机逻辑、收到告警后怎么保住 IP、换 IP 有哪些坑、被攻击产生的流量算谁的账单，以及怎么把入口挪出机房。
Q：为什么被DDoS攻击会被机房停机？
关键在于机房卖给你的带宽是「共享出口」里切出来的一块：
- 出口带宽共享：同一台交换机下面挂着很多客户，你的入向洪水会挤占整条上行，别人跟着遭殃。
- 投诉直接落到机房：邻居客户投诉的不是你，而是机房。机房处理投诉最省事的办法就是先把你断开。
- 上游运营商也会施压：流量打到一定规模，运营商会通知机房限流，机房再把压力转给你。
- 被攻击等于高风险客户：部分机房对「被攻击」接近零容忍，因为清洗设备要花钱，而你付的还是普通带宽的钱。
一句话：机房不替你扛攻击，它只对「影响到别人」零容忍。
Q：机房通常在什么情况下会动手？
机房的判断标准不是「你被打了多少」，而是「你有没有影响到别人」。常见触发点：
- 入向带宽持续超出售卖上限，且没有回落趋势。
- 出口出现明显异常流量形态，比如大量 UDP、ICMP，或频繁触发反射放大特征。
- 触发机房黑洞阈值，也就是一个自动丢弃全部流量的硬阈值。
- 收到上游或同机房客户的投诉，这是最危险的一种，往往直接跳到最后一步。
处置顺序通常是：先邮件通知 → 限速或封端口 → 强制下架并回收 IP。每一步之间留的时间很短，所以收到第一封通知时就要当成最高优先级处理。
Q：收到机房告警第一时间做什么？
三步并行：确认、止血、回话。确认攻击形态最快的方式是直接在源站抓包：
# 实时看入向流量与来源（需要 root）
iftop -i eth0 -n -N
# 抽样看流量以什么协议为主，定位攻击类型
tcpdump -i eth0 -nn -c 1000 'udp' | awk '{print $5}' | sort | uniq -c | sort -rn | head
# 连接维度汇总
ss -s
ss -ant state syn-recv | wc -l同一时间必须先给机房回话，哪怕还没定位完。回复内容至少包含「已确认异常、正在处置、预计 X 分钟内反馈」。沉默是最差的应对，机房看不到你在动，就会按最严措施处理。
Q：怎么和机房沟通才能保住 IP？
核心是给机房一个可执行的方案，而不是「我也没办法」。把下面这份材料准备好，越快给出保 IP 的概率越高：
- 攻击描述：类型（流量型或应用层）、规模（Mbps、pps、源 IP 数量）、开始时间。
- 已采取的止血动作：已限速到多少、已封哪些网段、是否已申请黑洞。
- 后续方案与时间表：比如「30 分钟内把域名切到高防，源站只对回源段放行」。
- 自我约束承诺：主动提出把源站入口限速到 XX Mbps 以内、只保留 80/443 端口。
- 业务说明：涉及备案信息的合规业务，机房通常愿意多给一点处理时间。
反过来，最容易被直接下架的回复是：「攻击是别人打的，跟我没关系」。这句话对机房没有意义，它要的是你现在能让流量降下来。
Q：被停机或封端口后怎么最快恢复？
先分清是「封端口」还是「整个 IP 被下架」：
# 本机自检服务是否正常
curl -s -o /dev/null -w '%{http_code}\n' --max-time 5 http://127.0.0.1/
# 从外部探测端口是否可达
nc -zv <机房网关IP> 80
nc -zv <机房网关IP> 443- 只是封端口：可以申请解封，但要附上整改计划；也可以临时换端口应急。
- IP 被下架：基本只能换 IP 或迁移，别指望机房回心转意。
- 业务优先：不管哪种情况，先把域名解析切到备用入口（CDN、高防、其他节点），让业务先恢复，再回头处理原 IP。
Q：换 IP 有哪些坑？
# 换 IP 前先把 TTL 调小，方便快速回切
# 示例：把 A 记录的 TTL 从 3600 改成 120
# www 120 IN A 203.0.113.10- TTL 一定要提前调：攻击发生时再去改解析，全球递归缓存可能要等几小时才生效。
- 备案变更：国内机房换 IP 通常要重新做接入备案或变更，没用备用入口的话会卡在这。
- 白名单要同步更新：支付回调、短信通道、第三方接口、防火墙白名单，全部跟着改，漏一个就是一个故障点。
- SEO 影响有限但要看时间：单纯换 IP 不影响排名，但如果长时间返回 5xx 或持续不可用，抓取配额会掉，恢复起来很慢。
- 新 IP 很快会被重新扫到：攻击者盯着你的域名，新入口同样需要带防护，否则只是把问题挪了个地方。
Q：怎么避免再次被机房停机？
答案是把入口从机房挪出去，让洪水根本不进机房：
# 源站只允许防护节点回源（Nginx）
location / {
allow 203.0.113.0/24; # 防护/CDN 回源段
deny all;
proxy_pass http://127.0.0.1:8080;
}- 域名解析指向 CDN 或高防，源站 IP 全程保密。
- 堵住源站 IP 泄露的口子：历史 DNS 记录、邮件头、SSL 证书透明度日志、第三方探针都可能暴露源站。
- 只保留必要端口：数据库、缓存的端口一律不要对公网开放。
- 提前和机房报备：说明业务已上防护、被攻击时会主动通知，避免机房在不知情时按最严措施处理。
小站的最优解通常就是这一条：域名前置到 CDN 或高防，源站只放行回源段，成本不高，但能同时解决「被打挂」和「被停机」两个问题。
Q：被攻击产生的带宽流量，账单算谁的？
这是个容易被忽略的成本问题。按流量或按峰值计费的模式下，攻击流量通常会照常计入你的账单，因为洪水是直达机房的，机房确实为你消耗了出口。要提前做三件事：
- 查合同条款：部分机房有「攻击流量不计费」或「提供一定额度黑洞保护」的约定，但必须提前书面确认。
- 优先选固定带宽：封顶模式虽然贵一点，但被攻击时不会产生天价账单。
- 设用量告警：跑到 80% 就告警，别等到月底看到账单才知道被打过。
如果确实产生了异常计费，保留完整的攻击日志和处置记录，用于向机房或服务商申诉，这是唯一能说得清的依据。
Q：还有什么补充建议？
- 买机器前先问三件事：会否因攻击停机、是否提供黑洞、攻击流量是否计费。
- 把 IP 当耗材管理：随时准备换，别把业务生死绑在一个 IP 上。
- 换机房不是解法：入口架构不改，换到哪一家都会遇到同样的问题。
- 留全证据链：攻击日志、机房通知邮件、处置动作时间线，申诉和报案都用得上。
- 常态化演练：把「机房通知 → 切备用入口 → 业务恢复」这条链路真正跑一遍，别等真被打时才发现脚本是坏的。
一句话总结：机房只对「影响别人」零容忍；保住 IP 靠的是给机房一个可执行方案，真正不被停机靠的是把入口挪出机房、把源站藏好、把 IP 当耗材管理。