新泽西高防服务器用于美国东海岸业务，遭遇CC攻击时先看哪些日志

排查目标：先把故障范围圈到同一个时间窗

美国东海岸业务部署在新泽西高防服务器上，用户反馈访问慢、接口超时，监控里同时出现 QPS 上升、CPU 抖动或 5xx 增多时，不要先急着把问题定性为 CC攻击。排查目标应先明确三件事：故障发生的准确时间段、异常影响的是公网入口还是源站应用、源站日志里看到的客户端 IP 是否是真实访客 IP。

建议按这个顺序看：先看防护侧事件和带宽/连接数曲线，确认是否触发清洗、限速或黑洞；再看源站连接数和系统负载，判断压力是否已经打到服务器；然后看 Web 访问日志、错误日志、状态码分布、URI 分布和请求耗时；最后再进入应用日志、数据库慢查询和缓存日志。这个顺序适用于日志完整、服务器时间同步、防护节点能正确透传真实客户端 IP 的场景。如果真实 IP 没有配置好，源站日志里可能只看到高防节点 IP，直接按 IP 封禁很容易误伤。

先排除外部因素：链路、清洗和业务高峰要分开看

新泽西机房靠近美国东海岸用户，适合面向纽约、华盛顿、波士顿等区域的业务入口。但地域优势不能替代故障判断。访问慢可能来自公网链路波动、上游清洗策略、回源带宽瓶颈，也可能是应用本身处理不过来。

排查时先向防护侧或控制台核对以下信息：

• 异常时间段的入方向带宽、包量、连接数、请求数是否突增；
• 是否触发清洗、牵引、限速、封禁、黑洞等事件；
• 异常端口是 80/443，还是数据库、游戏、TCP 长连接等其他端口；
• 防护节点到源站的回源连接是否正常；
• 是否有单地区、单运营商、单 ASN 或单 IP 段访问异常；
• 如果前面还有 CDN、WAF、SLB，需要同时查看它们的访问日志和规则命中记录。

正常流量高峰与 CC攻击的差异通常不只体现在“流量变大”，而是体现在访问行为是否符合业务逻辑。

需要注意，CC攻击不一定带来很高带宽。有些攻击请求体很小，但会打到消耗 CPU、数据库或第三方接口的路径，例如搜索、登录、验证码校验、复杂报表、库存查询。只看带宽容易漏判。

定位源站：先看 Web 日志，再看连接数和状态码

1. Web 访问日志：确认谁在访问、访问什么、频率多高

如果使用 Nginx，默认访问日志通常在 /var/log/nginx/access.log；Apache 在 RHEL/CentOS 系常见路径是 /var/log/httpd/access_log，在 Debian/Ubuntu 系常见路径是 /var/log/apache2/access.log。实际路径以站点配置为准，尤其是多虚拟主机、容器部署或自定义日志目录的环境。

先按故障时间截取日志，再统计来源 IP、URI 和状态码。以下命令只做读取和统计，不会修改文件：

# 查看指定时间段内访问最多的来源 IP，示例时间需替换为实际故障时间
sudo zgrep -h "03/Jul/2026:10:" /var/log/nginx/access.log* \
| awk '{print $1}' \
| sort | uniq -c | sort -nr | head -20

# 查看访问最多的 URI
sudo zgrep -h "03/Jul/2026:10:" /var/log/nginx/access.log* \
| awk '{print $7}' \
| sort | uniq -c | sort -nr | head -20

# 查看状态码分布
sudo zgrep -h "03/Jul/2026:10:" /var/log/nginx/access.log* \
| awk '{print $9}' \
| sort | uniq -c | sort -nr

如果服务器位于高防、WAF 或反向代理之后，$1 可能是代理节点 IP，而不是真实用户 IP。此时需要检查 Nginx 是否正确记录了 X-Forwarded-For、X-Real-IP 或防护产品指定的真实 IP 头。不能直接信任公网传入的 X-Forwarded-For，只应信任来自已知高防回源 IP 段的头部，否则攻击者可以伪造来源。

建议在访问日志中保留请求耗时、上游耗时、请求头和真实 IP 字段，便于排障。示例配置如下，修改前请先备份配置，并确认变量适用于当前 Nginx 版本：

log_format main_ext '$remote_addr $http_x_forwarded_for - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" '
                    'rt=$request_time urt=$upstream_response_time '
                    'host=$host';

access_log /var/log/nginx/access.log main_ext;

修改后先检查配置，再平滑加载：

sudo nginx -t
sudo systemctl reload nginx

2. 连接数：确认压力是否已经打到源站

Web 日志能说明请求行为，连接数能说明源站当前承压情况。CC攻击常见现象包括 ESTAB 连接快速升高、TIME-WAIT 大量堆积、应用 worker 被占满、反向代理队列变长。

# 查看 80/443 相关连接状态分布
sudo ss -ant | awk '$4 ~ /:80$|:443$/ {state[$1]++} END {for (s in state) print s, state[s]}'

# 查看 443 端口当前已建立连接数
sudo ss -ant state established '( sport = :443 )' | wc -l

# 查看系统负载、CPU 等待和内存压力
uptime
free -h
top

如果安装了 sysstat，可以补充看 TCP 重传、连接错误和网卡吞吐：

sar -n TCP,ETCP 1 5
sar -n DEV 1 5

连接数高不一定就是 CC攻击。正常直播、下载、WebSocket、长轮询也会提高连接数。关键要结合 URI、请求间隔、业务指标和应用线程池状态一起看。

3. 状态码：不要只盯着 5xx

很多人看到 502、504 才开始怀疑攻击，但 CC攻击也可能大量返回 200。因为攻击请求可能成功命中动态接口，只是把数据库、缓存、PHP-FPM、Java 线程池或 Node.js 事件循环拖慢。

常见状态码可以这样判断：

如果 access log 中有 request_time 和 upstream_response_time，可以区分慢在 Nginx 接收阶段、应用处理阶段还是上游依赖阶段。request_time 高而 upstream_response_time 也高，通常说明后端处理慢；upstream_response_time 为 -，可能请求没有成功转发到上游。

结果分支：按证据判断是高峰、CC 还是源站瓶颈

分支一：正常业务高峰

如果访问来源分散，URI 与活动入口一致，订单、注册、下载、API 调用等业务指标同步上升，且没有明显异常请求头或固定频率请求，优先按容量问题处理。此时重点不是封禁，而是扩容、缓存、队列削峰和静态资源分离。

对于非攻击型大流量网站，带宽和磁盘 I/O 也要纳入选型。LHIDC 当前资料中，美国 AMD 大带宽服务器采用 AMD EPYC 7402P、64G 内存、960G NVMe Gen4，可选 1G 三网直连或 3G 国际带宽，适用于视频点播、文件下载、跨境业务和大流量网站。若业务是 API、企业站或跨境电商，也可根据访问地区、线路和带宽需求评估美国三网优化服务器，其配置为 AMD EPYC 4244P、32G DDR5-4800、960G NVMe SSD、100M CN2。是否需要新泽西高防服务器，应取决于攻击风险、目标用户区域和防护需求，而不是只看单次流量峰值。

分支二：疑似 CC攻击

如果短时间内某些动态接口请求量暴涨，来源行为高度一致，业务转化没有同步提升，连接数和应用耗时同时升高，就要按 CC攻击处理。此时不要只在源站上硬抗，应同时让防护侧和应用侧协同。

可提交给防护侧的信息包括：

• 异常时间段，精确到分钟；
• 被刷的域名、URI、端口和协议；
• Top IP、Top URI、Top User-Agent；
• 状态码分布和请求耗时变化；
• 是否影响登录、支付、搜索、详情页等关键路径；
• 是否可以临时提高验证、限速或拦截策略。

这些信息能帮助高防侧制定更准确的清洗和应用层规则。具体防护能力、清洗策略、日志粒度和响应方式，需要以当前开通的新泽西高防服务器产品、附加防护服务和合同范围为准，不应默认所有 CC 场景都能被完全拦截。

分支三：源站自身瓶颈

如果防护侧没有异常事件，入口流量也没有明显暴涨，但源站 502/504、数据库慢查询、线程池耗尽或缓存超时明显增加，就要回到应用链路排查。典型原因包括：

• 慢 SQL 或缺少索引；
• 缓存穿透、缓存雪崩；
• PHP-FPM、Gunicorn、Tomcat、Node.js worker 数配置不合理；
• 第三方接口超时导致请求堆积；
• 日志同步写入过慢；
• 静态资源未缓存，全部打到源站。

这种情况即使放在高防服务器上，也不能只依赖防护。高防解决的是入口安全和流量清洗问题，应用性能瓶颈仍需要在代码、数据库、缓存和架构层处理。

修复：高防能力与应用层限流要分工明确

高防服务器的价值在于把异常流量尽量拦在源站外，尤其是大流量、异常连接、恶意请求特征明显的场景。但应用层接口是否昂贵、用户是否已登录、某个账号是否异常、某个业务动作是否允许高频调用，只有应用系统最清楚。

Nginx 可以做基础限流，但上线前必须确认真实 IP 配置正确。以下示例仅用于说明思路，具体阈值需要按业务压测和正常峰值确定：

http {
    limit_req_zone $binary_remote_addr zone=perip:20m rate=5r/s;

    server {
        listen 443 ssl;
        server_name example.com;

        location /api/ {
            limit_req zone=perip burst=20 nodelay;
            proxy_pass http://backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

如果源站位于高防节点后面，并且要按真实访客 IP 限流，应只对可信高防回源 IP 段启用 real IP 解析。示例中的 IP 段必须替换为实际产品提供的回源地址段：

set_real_ip_from 203.0.113.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

配置变更前先备份，变更后执行：

sudo nginx -t
sudo systemctl reload nginx

对于登录、注册、搜索、发送验证码、导出报表等接口，更建议在应用层增加按账号、设备、Token、会话和业务动作的限流。只按 IP 限制在美国业务中可能误伤公司出口、校园网、移动运营商 NAT 用户，也可能对分布式 CC 效果有限。

回归验证：看拦截是否生效，也要看正常用户是否恢复

处理后不要只看服务器负载下降。回归验证应至少覆盖四组指标：

1. 防护侧：清洗事件是否仍在持续，异常请求是否下降，是否出现误封正常地区或正常 IP 段；
2. Web 层：Top URI 是否恢复正常，429/403/499/502/504 是否回落，request_time 是否下降；
3. 应用层：线程池、连接池、队列长度、错误日志、慢查询是否恢复；
4. 用户侧：美国东海岸主要访问地区是否能正常打开页面，关键接口是否可用，登录、下单、支付、表单提交是否正常。

如果临时加了严格规则，例如封禁地区、提高验证码频率、限制某些接口访问，建议记录变更时间、规则内容、影响范围和回滚条件。攻击缓解后逐步放松策略，避免长期影响真实用户。

新泽西高防服务器适合作为美国东海岸业务的防护入口，但不能替代源站日志、应用限流和容量规划。采购或升级前应核对防护范围、清洗能力、回源方式、日志可见性、带宽计费、是否支持 HTTPS 七层策略以及应急响应流程；这些内容以 LHIDC 当前产品说明和合同为准。若故障处理过程中无法确认异常来源，先保留日志和监控截图，再调整规则，避免在证据不足时扩大误伤或掩盖真正的应用瓶颈。