1. 从一次“流量攻击”说起个人站长的真实困境今天想和大家聊聊一个很多独立开发者、博主都可能会遇到但网上系统化解决方案不多的实际问题你的个人网站突然被恶意流量“盯上”了。我说的不是那种动辄数百G的DDoS攻击那种量级个人站基本无解得靠云厂商的高防。我指的是更常见、更“恶心”的一种情况你的网站日志里突然出现大量来自某个或某几个IP的、高频的、无意义的请求。它们可能疯狂刷新你的首页可能遍历你根本不存在的文章ID也可能针对某个登录接口或评论提交页面进行高频试探。这种访问不会立刻让你的服务器宕机如果你的配置不是太差的话但它会像牛皮癣一样持续消耗你的服务器资源——CPU、内存、特别是数据库连接和带宽。最直观的感受就是网站变慢了后台打开像便秘甚至偶尔会直接返回502错误。更关键的是它会影响你的心情让你觉得自己的小天地被人“玷污”了。我自己的一个技术博客就遇到过某天发现阿里云控制台报警CPU持续在80%以上一查日志一个IP段在每秒几十次地请求/wp-admin和/xmlrpc.php持续了快一天。这显然不是正常用户行为。面对这种情况很多新手站长会手足无措要么选择硬扛眼睁睁看着服务器资源被耗光要么病急乱投医在网上找一些复杂的防火墙规则结果可能误伤正常用户。其实处理这类“中小规模恶意访问”核心思路不在于配置多么高深的武器而在于建立一套清晰、有效、可执行的防御体系。这就像家里防盗你不是要去造一个银行金库而是把门窗锁好装个监控让小偷觉得你家麻烦转而去找更容易的目标。接下来我就结合自己的实战经验从监控发现、应急处理、主动防御到成本优化拆解一下个人网站应对恶意访问的完整思路和可落地方案。我们追求的不是绝对安全那不存在而是在有限的精力和预算下实现最高性价比的防护。2. 防御体系构建从监控到响应的四层策略处理安全问题最忌讳的就是头痛医头脚痛医脚。我们必须建立一个系统性的思维。对于个人网站我将其归纳为四个层次监控发现层、应急处理层、主动防御层和架构优化层。这四层由浅入深共同构成了一个动态的防御闭环。2.1 第一层监控发现——你的“安全眼睛”你无法防御一个你看不见的敌人。因此建立有效的监控是第一步。对于个人站点我们不需要像企业那样部署复杂的SIEM系统用好手边的工具就足够了。核心监控点有三个服务器资源、访问日志和网络流量。服务器资源监控这是最基础的。利用云服务商提供的监控面板如阿里云云监控、腾讯云云监控重点关注CPU使用率、内存使用率、磁盘IO和网络流入流出带宽。设置合理的报警阈值比如CPU持续5分钟超过70%就发短信或钉钉通知你。这能让你在问题变得严重之前就得到预警。访问日志分析这是定位问题根源的关键。以最常用的Nginx为例日志通常位于/var/log/nginx/access.log。你需要学会快速分析它。我常用的命令组合是# 实时查看日志尾部 tail -f /var/log/nginx/access.log # 统计最近1000行日志中访问量最高的前10个IP tail -n 1000 /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr | head -10 # 统计特定可疑路径如wp-login.php的访问 grep wp-login.php /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr通过这些命令你可以迅速找出哪个IP在“作怪”以及它在攻击哪个页面。如果发现某个IP在短时间内如1分钟对同一个非静态页面如图片、CSS文件以外的页面请求了上百次那基本可以判定为恶意行为。网络流量监控如果你使用了CDN如Cloudflare那么CDN的控制台是更强大的监控工具。它能清晰地展示请求来源国家/地区、热门请求路径、攻击类型如CC攻击等信息比直接看服务器日志更直观。注意监控不是装好就完事了。你需要养成定期比如每天花5分钟看一眼日志和监控面板的习惯。很多小规模的试探性攻击就是在你不注意的时候开始的。2.2 第二层应急处理——“救火”三板斧当监控报警响起或者你手动发现网站异常时需要立刻进行应急处理目标是快速恢复服务阻断攻击源。这里有三板斧按顺序使用。第一板斧IP层面封禁最快最直接。一旦锁定恶意IP立即在服务器防火墙或Web服务器层进行封禁。使用服务器防火墙推荐比如iptablesCentOS或ufwUbuntu。# 使用iptables封禁单个IP例如 1.2.3.4 iptables -I INPUT -s 1.2.3.4 -j DROP # 封禁整个IP段例如 1.2.3.0/24 iptables -I INPUT -s 1.2.3.0/24 -j DROP # 保存规则防止重启后失效CentOS 7 service iptables save # 或使用iptables-persistentUbuntu apt-get install iptables-persistent netfilter-persistent save使用Nginx封禁在Nginx配置文件的server块或http块中使用deny指令。location / { deny 1.2.3.4; deny 2.3.4.0/24; # ... 其他配置 }修改后记得重载Nginxnginx -s reload。这种方式生效快但只针对Web服务。第二板斧限制请求频率应对CC攻击。有些攻击会使用代理IP或肉鸡IP不固定封不过来。这时就需要限制单个IP的请求频率。Nginx的limit_req模块是神器。http { # 定义一个名为perip的限流区速率10r/s每秒10次突发队列5个 limit_req_zone $binary_remote_addr zoneperip:10m rate10r/s; server { location / { # 应用限流突发请求延迟处理无延迟参数则超出的直接返回503 limit_req zoneperip burst5 nodelay; # ... 其他配置 } # 对后台登录等敏感页面可以设置更严格的限制 location ~* ^/(wp-admin|wp-login|admin) { limit_req zoneperip burst3 nodelay; } } }这个配置意味着同一个IP访问网站平均速率不能超过每秒10次短时间内允许有5个突发请求会被延迟处理超过这个限制的请求Nginx会直接返回503错误。对于后台页面限制更严。第三板斧验证码与挑战增加攻击成本。对于登录、注册、评论提交等交互接口引入验证码如Google reCAPTCHA或简单的JS挑战可以极大增加自动化脚本的攻击成本。很多攻击脚本无法执行JS或解析复杂验证码。对于WordPress等程序有大量插件可以实现此功能。实操心得应急时优先使用iptables全局封禁效果立竿见影。limit_req配置需要调整参数rate和burst设得太低会影响正常用户比如搜索引擎爬虫设得太高又没效果。我的经验是对于普通内容站rate10r/sburst20是个不错的起点然后根据日志观察调整。对于后台可以直接设为rate2r/sburst5。2.3 第三层主动防御——让攻击者“知难而退”应急处理是事后补救主动防御则是事前设防目标是提高攻击门槛让大部分自动化工具和脚本觉得你的网站“不好惹”。1. 隐藏关键入口与信息修改默认后台地址不要用/wp-admin/admin这种默认地址。对于WordPress可以通过插件或修改代码来改变登录URL。禁用XML-RPCWordPress的XML-RPC接口是暴力破解的重灾区。如果你不用移动客户端发布文章强烈建议在Nginx层面或通过插件禁用它。location ~* ^/xmlrpc\.php$ { deny all; return 444; }隐藏服务器信息在Nginx配置中关闭server_tokens避免暴露Nginx版本。http { server_tokens off; }2. 利用CDN的防护能力这是个人站长性价比最高的防护手段。以Cloudflare免费版为例开启“Under Attack”模式在遭受攻击时临时开启此模式所有访问者都需要先通过一个JS挑战页面才能访问你的网站能有效过滤掉大量自动化流量。配置防火墙规则在Cloudflare面板的“安全性”-“WAF”-“防火墙规则”中可以创建基于IP、国家、ASN、请求头、路径等条件的规则。例如可以创建一个规则拦截所有对/wp-login.php且请求频率超过每分钟10次的IP。启用速率限制Cloudflare付费版提供更精细的速率限制规则免费版可以通过防火墙规则模拟实现部分功能。3. 使用Fail2ban自动封禁这是一个守护进程可以监控系统日志如Nginx的认证错误日志并根据你定义的规则自动将多次失败尝试的IP加入防火墙黑名单。配置稍复杂但一劳永逸。# 安装Fail2ban apt-get install fail2ban # 复制默认的jail配置进行修改 cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local然后编辑/etc/fail2ban/jail.local为Nginx添加一个监控监狱jail[nginx-http-auth] enabled true filter nginx-http-auth port http,https logpath /var/log/nginx/error.log maxretry 5 bantime 3600这个配置表示如果同一个IP在/var/log/nginx/error.log中因HTTP认证失败被记录5次Fail2ban就会自动用iptables封禁该IP1小时。2.4 第四层架构优化——提升“自身免疫力”前面三层都是在“堵”这一层则是“疏”和“强身健体”通过优化架构来提升网站的承载能力和抗压性。1. 全站静态化这是应对读取型恶意访问的终极方案之一。如果你的网站主要是博客、文档等不常变化的内容使用静态网站生成器如Hugo, Hexo, Jekyll将内容生成纯HTML文件然后部署到Netlify、Vercel或云对象存储OSS/COS上。静态文件几乎没有计算开销服务器只负责传输文件抗压能力极强成本也极低。即使遭遇大量请求也主要是带宽消耗。2. 动静分离与缓存加速动静分离将图片、CSS、JS等静态资源与动态程序如PHP分离使用独立的域名如static.yoursite.com并托管到对象存储CDN上。这能极大减轻应用服务器的压力。各级缓存浏览器缓存通过设置HTTP头如Cache-Control,Expires让用户浏览器缓存静态资源。CDN缓存配置CDN缓存你的静态资源甚至部分动态页面。服务器缓存使用Redis或Memcached作为数据库查询缓存、对象缓存。对于WordPress安装Redis Object Cache插件并正确配置能将数据库查询减少80%以上。OPcache对于PHP应用务必启用并配置OPcache它能将编译后的PHP脚本字节码缓存到内存避免每次请求都重新编译大幅提升PHP执行效率。3. 数据库优化很多恶意访问的目的是拖垮数据库。确保你的数据表建立了合适的索引避免全表扫描。定期清理无用数据如垃圾评论、修订版本。对于WordPress可以使用插件或手动SQL语句进行优化。4. 升级服务器配置最后手段如果以上方法都用了流量攻击依然持续且影响了正常用户可以考虑临时升级服务器配置如增加CPU、内存或者迁移到更高性能的实例。但这属于“氪金”解决方案应作为最后的选择。3. 实战一次完整的恶意流量处置记录光讲理论不够我分享一个上个月处理我某个子站的真实案例把上面的策略串起来。背景一个用WordPress搭建的技术分享站运行在1核2G的云服务器上使用了阿里云CDN。第一阶段发现异常监控层某个周一下午收到阿里云云监控的报警短信“CPU使用率持续超过85%”。登录服务器用htop命令看到CPU主要是被PHP-FPM进程吃满的。立刻检查Nginx日志tail -f /var/log/nginx/access.log发现大量POST /wp-login.php和GET /?author1的请求来自几十个不同的IP但IP段相对集中属于同一个海外数据中心。请求频率极高单个IP每秒可达数十次。这明显是针对WordPress的密码暴力破解和用户信息枚举扫描。第二阶段紧急处置应急处理层IP封禁由于IP数量还不是特别多约50个我首先通过脚本快速提取这些IP并用iptables批量封禁。# 从日志中提取过去5分钟内访问/wp-login.php超过20次的IP grep date -d ‘-5 min’ %d/%b/%Y:%H:%M /var/log/nginx/access.log | grep “POST /wp-login.php” | awk ‘{print $1}’ | sort | uniq -c | sort -nr | awk ‘$120 {print $2}’ bad_ips.txt # 批量加入iptables规则 while read ip; do iptables -I INPUT -s $ip -j DROP; done bad_ips.txt执行后CPU负载立刻从90%降到了40%左右。启用严格限流我修改了Nginx配置对登录相关路径应用更严格的限流。location ~* ^/(wp-login\.php|xmlrpc\.php) { limit_req zoneperip burst3 nodelay; deny all; # 实际上我先用deny all完全屏蔽待确认规则后调整 # ... 其他配置 }这里我先用了deny all快速阻断因为我知道这个站暂时没有远程发布需求。然后重载Nginx。第三阶段加固防御主动防御层Cloudflare防火墙规则我的域名解析在Cloudflare。我登录CF面板创建了一条防火墙规则规则表达式(http.request.uri.path contains “wp-login.php”) or (http.request.uri.path contains “xmlrpc.php”)操作Managed Challenge托管质询 这条规则会让所有访问这两个路径的流量先经过一个Cloudflare的JS挑战能过滤掉99%的自动化脚本。修改登录地址我安装了一个名为“WPS Hide Login”的轻量级插件将登录地址从/wp-login.php改为了一个随机的字符串路径比如/my-secret-login-door。这样之前的攻击脚本全部失效。启用Fail2ban我配置了Fail2ban来监控Nginx的访问日志自动封禁那些频繁访问不存在页面404和登录页的IP。第四阶段长期优化架构优化层全面启用缓存我检查并确保了Redis对象缓存插件正常运行将数据库查询命中率从30%提升到了95%。同时优化了CDN缓存规则将更多静态化页面如文章页、分类页缓存起来。考虑静态化因为这个站内容更新不频繁我开始评估将其迁移到Hugo静态生成器的可行性以从根本上杜绝此类PHP层面的攻击。整个处置过程大约花了2小时其中大部分时间在分析日志和验证规则效果。之后一周该站点再未出现类似的恶意流量高峰。4. 常见问题与排查技巧实录在实际操作中你肯定会遇到各种问题。下面是我总结的一些常见坑点和排查思路。Q1封禁IP后网站依然很慢CPU还是高。可能原因1攻击源IP已经更换或者使用了大量代理IP。你封禁的速度赶不上它更换的速度。排查再次分析最新日志看是否出现了新的IP段。使用iftop或nethogs命令查看实时的网络连接和带宽占用找出当前活跃的异常连接。解决从“封IP”转向“限频率”。立即启用Nginx的limit_req模块针对全站或特定路径进行速率限制。同时考虑启用Cloudflare的“Under Attack”模式或设置基于行为的WAF规则。Q2配置了Nginx限流limit_req但好像没效果。可能原因1配置作用域不对。limit_req指令需要放在http,server,location块中且limit_req_zone必须放在http块。检查你的配置语法和位置。可能原因2burst参数设置过大且没有nodelay。假设rate10r/sburst50没有nodelay。那么前50个超额请求会被放入队列延迟处理而不是立即拒绝这依然会占用服务器资源。在遭受攻击时建议使用nodelay。排查可以在Nginx日志格式中添加$limit_req_status变量查看每个请求的限流状态。log_format main ‘$remote_addr – $remote_user [$time_local] “$request” ‘ ‘$status $body_bytes_sent “$http_referer” ‘ ‘“$http_user_agent” “$http_x_forwarded_for” ‘ ‘“$limit_req_status”‘;然后查看日志如果看到大量PASSED以外的状态如DELAYED,REJECTED说明限流在起作用。Q3使用了Cloudflare但服务器真实IP被泄露攻击者绕过CDN直接攻击源站。可能原因这是非常常见且危险的问题。你的服务器可能通过其他方式暴露了IP例如邮件服务器使用了相同IP、网站代码中硬编码了服务器IP、通过某些在线工具查询到了历史解析记录等。解决严格隔离确保服务器上所有服务网站、邮件、数据库等都不直接暴露真实IP。可以为源站服务器再套一层防火墙安全组只允许Cloudflare的IP段访问你的80/443端口。Cloudflare官方公布了它的IP列表你需要定期更新防火墙规则。更换服务器IP如果IP已经暴露且持续被攻击最彻底的方法是更换服务器的公网IP地址。使用“源站屏蔽”在Cloudflare的SSL/TLS设置中将“加密模式”设置为“完全严格”并在源站服务器上安装并配置Cloudflare的Origin CA证书这样只有来自Cloudflare且携带有效证书的请求才能被源站接受。Q4误封了正常用户或搜索引擎蜘蛛如百度、Googlebot。预防在设置任何封禁或限流规则时务必为已知的友好爬虫和自身IP设置白名单。Nginx白名单示例# 定义白名单IP geo $whitelist { default 0; 1.2.3.4 1; # 你的办公室IP 8.8.8.8 1; # 示例实际需用搜索引擎官方IP段 } map $whitelist $limit { 0 $binary_remote_addr; 1 “”; } limit_req_zone $limit zoneperip:10m rate10r/s;Cloudflare防火墙规则创建一条规则当IP地址属于“已知爬虫”时跳过所有其他安全规则。补救定期检查被封禁的IP列表如iptables -L -n如果发现误封及时移除。对于Fail2ban可以查看/var/log/fail2ban.log并修改ignoreip配置项。Q5网站使用了WebSocket或API限流规则影响了正常功能。解决为特定的API路径或WebSocket连接路径设置独立的、更宽松的限流区域或者将其从全局限流中排除。location /api/ { # 为API设置独立的限流速率可以高一些 limit_req zoneapi_perip burst30 nodelay; # … API代理配置 } location /ws/ { # WebSocket连接可能不需要限流或者设置很宽松的限制 # limit_req zonews_perip burst50 nodelay; # … WebSocket代理配置 }处理恶意访问是一个持续对抗的过程。没有一劳永逸的方案核心在于建立监控-响应-加固的闭环习惯。开始的时候可能会觉得麻烦但当你配置好一套自动化工具如Fail2banCloudflare规则后日常维护成本会变得非常低。最重要的是保持冷静按照监控、分析、处置、加固的步骤来你的个人小站就能在绝大多数情况下保持安稳。
个人网站恶意流量防御实战：从监控到架构的四层防护体系
发布时间：2026/7/2 6:13:51
1. 从一次“流量攻击”说起个人站长的真实困境今天想和大家聊聊一个很多独立开发者、博主都可能会遇到但网上系统化解决方案不多的实际问题你的个人网站突然被恶意流量“盯上”了。我说的不是那种动辄数百G的DDoS攻击那种量级个人站基本无解得靠云厂商的高防。我指的是更常见、更“恶心”的一种情况你的网站日志里突然出现大量来自某个或某几个IP的、高频的、无意义的请求。它们可能疯狂刷新你的首页可能遍历你根本不存在的文章ID也可能针对某个登录接口或评论提交页面进行高频试探。这种访问不会立刻让你的服务器宕机如果你的配置不是太差的话但它会像牛皮癣一样持续消耗你的服务器资源——CPU、内存、特别是数据库连接和带宽。最直观的感受就是网站变慢了后台打开像便秘甚至偶尔会直接返回502错误。更关键的是它会影响你的心情让你觉得自己的小天地被人“玷污”了。我自己的一个技术博客就遇到过某天发现阿里云控制台报警CPU持续在80%以上一查日志一个IP段在每秒几十次地请求/wp-admin和/xmlrpc.php持续了快一天。这显然不是正常用户行为。面对这种情况很多新手站长会手足无措要么选择硬扛眼睁睁看着服务器资源被耗光要么病急乱投医在网上找一些复杂的防火墙规则结果可能误伤正常用户。其实处理这类“中小规模恶意访问”核心思路不在于配置多么高深的武器而在于建立一套清晰、有效、可执行的防御体系。这就像家里防盗你不是要去造一个银行金库而是把门窗锁好装个监控让小偷觉得你家麻烦转而去找更容易的目标。接下来我就结合自己的实战经验从监控发现、应急处理、主动防御到成本优化拆解一下个人网站应对恶意访问的完整思路和可落地方案。我们追求的不是绝对安全那不存在而是在有限的精力和预算下实现最高性价比的防护。2. 防御体系构建从监控到响应的四层策略处理安全问题最忌讳的就是头痛医头脚痛医脚。我们必须建立一个系统性的思维。对于个人网站我将其归纳为四个层次监控发现层、应急处理层、主动防御层和架构优化层。这四层由浅入深共同构成了一个动态的防御闭环。2.1 第一层监控发现——你的“安全眼睛”你无法防御一个你看不见的敌人。因此建立有效的监控是第一步。对于个人站点我们不需要像企业那样部署复杂的SIEM系统用好手边的工具就足够了。核心监控点有三个服务器资源、访问日志和网络流量。服务器资源监控这是最基础的。利用云服务商提供的监控面板如阿里云云监控、腾讯云云监控重点关注CPU使用率、内存使用率、磁盘IO和网络流入流出带宽。设置合理的报警阈值比如CPU持续5分钟超过70%就发短信或钉钉通知你。这能让你在问题变得严重之前就得到预警。访问日志分析这是定位问题根源的关键。以最常用的Nginx为例日志通常位于/var/log/nginx/access.log。你需要学会快速分析它。我常用的命令组合是# 实时查看日志尾部 tail -f /var/log/nginx/access.log # 统计最近1000行日志中访问量最高的前10个IP tail -n 1000 /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr | head -10 # 统计特定可疑路径如wp-login.php的访问 grep wp-login.php /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr通过这些命令你可以迅速找出哪个IP在“作怪”以及它在攻击哪个页面。如果发现某个IP在短时间内如1分钟对同一个非静态页面如图片、CSS文件以外的页面请求了上百次那基本可以判定为恶意行为。网络流量监控如果你使用了CDN如Cloudflare那么CDN的控制台是更强大的监控工具。它能清晰地展示请求来源国家/地区、热门请求路径、攻击类型如CC攻击等信息比直接看服务器日志更直观。注意监控不是装好就完事了。你需要养成定期比如每天花5分钟看一眼日志和监控面板的习惯。很多小规模的试探性攻击就是在你不注意的时候开始的。2.2 第二层应急处理——“救火”三板斧当监控报警响起或者你手动发现网站异常时需要立刻进行应急处理目标是快速恢复服务阻断攻击源。这里有三板斧按顺序使用。第一板斧IP层面封禁最快最直接。一旦锁定恶意IP立即在服务器防火墙或Web服务器层进行封禁。使用服务器防火墙推荐比如iptablesCentOS或ufwUbuntu。# 使用iptables封禁单个IP例如 1.2.3.4 iptables -I INPUT -s 1.2.3.4 -j DROP # 封禁整个IP段例如 1.2.3.0/24 iptables -I INPUT -s 1.2.3.0/24 -j DROP # 保存规则防止重启后失效CentOS 7 service iptables save # 或使用iptables-persistentUbuntu apt-get install iptables-persistent netfilter-persistent save使用Nginx封禁在Nginx配置文件的server块或http块中使用deny指令。location / { deny 1.2.3.4; deny 2.3.4.0/24; # ... 其他配置 }修改后记得重载Nginxnginx -s reload。这种方式生效快但只针对Web服务。第二板斧限制请求频率应对CC攻击。有些攻击会使用代理IP或肉鸡IP不固定封不过来。这时就需要限制单个IP的请求频率。Nginx的limit_req模块是神器。http { # 定义一个名为perip的限流区速率10r/s每秒10次突发队列5个 limit_req_zone $binary_remote_addr zoneperip:10m rate10r/s; server { location / { # 应用限流突发请求延迟处理无延迟参数则超出的直接返回503 limit_req zoneperip burst5 nodelay; # ... 其他配置 } # 对后台登录等敏感页面可以设置更严格的限制 location ~* ^/(wp-admin|wp-login|admin) { limit_req zoneperip burst3 nodelay; } } }这个配置意味着同一个IP访问网站平均速率不能超过每秒10次短时间内允许有5个突发请求会被延迟处理超过这个限制的请求Nginx会直接返回503错误。对于后台页面限制更严。第三板斧验证码与挑战增加攻击成本。对于登录、注册、评论提交等交互接口引入验证码如Google reCAPTCHA或简单的JS挑战可以极大增加自动化脚本的攻击成本。很多攻击脚本无法执行JS或解析复杂验证码。对于WordPress等程序有大量插件可以实现此功能。实操心得应急时优先使用iptables全局封禁效果立竿见影。limit_req配置需要调整参数rate和burst设得太低会影响正常用户比如搜索引擎爬虫设得太高又没效果。我的经验是对于普通内容站rate10r/sburst20是个不错的起点然后根据日志观察调整。对于后台可以直接设为rate2r/sburst5。2.3 第三层主动防御——让攻击者“知难而退”应急处理是事后补救主动防御则是事前设防目标是提高攻击门槛让大部分自动化工具和脚本觉得你的网站“不好惹”。1. 隐藏关键入口与信息修改默认后台地址不要用/wp-admin/admin这种默认地址。对于WordPress可以通过插件或修改代码来改变登录URL。禁用XML-RPCWordPress的XML-RPC接口是暴力破解的重灾区。如果你不用移动客户端发布文章强烈建议在Nginx层面或通过插件禁用它。location ~* ^/xmlrpc\.php$ { deny all; return 444; }隐藏服务器信息在Nginx配置中关闭server_tokens避免暴露Nginx版本。http { server_tokens off; }2. 利用CDN的防护能力这是个人站长性价比最高的防护手段。以Cloudflare免费版为例开启“Under Attack”模式在遭受攻击时临时开启此模式所有访问者都需要先通过一个JS挑战页面才能访问你的网站能有效过滤掉大量自动化流量。配置防火墙规则在Cloudflare面板的“安全性”-“WAF”-“防火墙规则”中可以创建基于IP、国家、ASN、请求头、路径等条件的规则。例如可以创建一个规则拦截所有对/wp-login.php且请求频率超过每分钟10次的IP。启用速率限制Cloudflare付费版提供更精细的速率限制规则免费版可以通过防火墙规则模拟实现部分功能。3. 使用Fail2ban自动封禁这是一个守护进程可以监控系统日志如Nginx的认证错误日志并根据你定义的规则自动将多次失败尝试的IP加入防火墙黑名单。配置稍复杂但一劳永逸。# 安装Fail2ban apt-get install fail2ban # 复制默认的jail配置进行修改 cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local然后编辑/etc/fail2ban/jail.local为Nginx添加一个监控监狱jail[nginx-http-auth] enabled true filter nginx-http-auth port http,https logpath /var/log/nginx/error.log maxretry 5 bantime 3600这个配置表示如果同一个IP在/var/log/nginx/error.log中因HTTP认证失败被记录5次Fail2ban就会自动用iptables封禁该IP1小时。2.4 第四层架构优化——提升“自身免疫力”前面三层都是在“堵”这一层则是“疏”和“强身健体”通过优化架构来提升网站的承载能力和抗压性。1. 全站静态化这是应对读取型恶意访问的终极方案之一。如果你的网站主要是博客、文档等不常变化的内容使用静态网站生成器如Hugo, Hexo, Jekyll将内容生成纯HTML文件然后部署到Netlify、Vercel或云对象存储OSS/COS上。静态文件几乎没有计算开销服务器只负责传输文件抗压能力极强成本也极低。即使遭遇大量请求也主要是带宽消耗。2. 动静分离与缓存加速动静分离将图片、CSS、JS等静态资源与动态程序如PHP分离使用独立的域名如static.yoursite.com并托管到对象存储CDN上。这能极大减轻应用服务器的压力。各级缓存浏览器缓存通过设置HTTP头如Cache-Control,Expires让用户浏览器缓存静态资源。CDN缓存配置CDN缓存你的静态资源甚至部分动态页面。服务器缓存使用Redis或Memcached作为数据库查询缓存、对象缓存。对于WordPress安装Redis Object Cache插件并正确配置能将数据库查询减少80%以上。OPcache对于PHP应用务必启用并配置OPcache它能将编译后的PHP脚本字节码缓存到内存避免每次请求都重新编译大幅提升PHP执行效率。3. 数据库优化很多恶意访问的目的是拖垮数据库。确保你的数据表建立了合适的索引避免全表扫描。定期清理无用数据如垃圾评论、修订版本。对于WordPress可以使用插件或手动SQL语句进行优化。4. 升级服务器配置最后手段如果以上方法都用了流量攻击依然持续且影响了正常用户可以考虑临时升级服务器配置如增加CPU、内存或者迁移到更高性能的实例。但这属于“氪金”解决方案应作为最后的选择。3. 实战一次完整的恶意流量处置记录光讲理论不够我分享一个上个月处理我某个子站的真实案例把上面的策略串起来。背景一个用WordPress搭建的技术分享站运行在1核2G的云服务器上使用了阿里云CDN。第一阶段发现异常监控层某个周一下午收到阿里云云监控的报警短信“CPU使用率持续超过85%”。登录服务器用htop命令看到CPU主要是被PHP-FPM进程吃满的。立刻检查Nginx日志tail -f /var/log/nginx/access.log发现大量POST /wp-login.php和GET /?author1的请求来自几十个不同的IP但IP段相对集中属于同一个海外数据中心。请求频率极高单个IP每秒可达数十次。这明显是针对WordPress的密码暴力破解和用户信息枚举扫描。第二阶段紧急处置应急处理层IP封禁由于IP数量还不是特别多约50个我首先通过脚本快速提取这些IP并用iptables批量封禁。# 从日志中提取过去5分钟内访问/wp-login.php超过20次的IP grep date -d ‘-5 min’ %d/%b/%Y:%H:%M /var/log/nginx/access.log | grep “POST /wp-login.php” | awk ‘{print $1}’ | sort | uniq -c | sort -nr | awk ‘$120 {print $2}’ bad_ips.txt # 批量加入iptables规则 while read ip; do iptables -I INPUT -s $ip -j DROP; done bad_ips.txt执行后CPU负载立刻从90%降到了40%左右。启用严格限流我修改了Nginx配置对登录相关路径应用更严格的限流。location ~* ^/(wp-login\.php|xmlrpc\.php) { limit_req zoneperip burst3 nodelay; deny all; # 实际上我先用deny all完全屏蔽待确认规则后调整 # ... 其他配置 }这里我先用了deny all快速阻断因为我知道这个站暂时没有远程发布需求。然后重载Nginx。第三阶段加固防御主动防御层Cloudflare防火墙规则我的域名解析在Cloudflare。我登录CF面板创建了一条防火墙规则规则表达式(http.request.uri.path contains “wp-login.php”) or (http.request.uri.path contains “xmlrpc.php”)操作Managed Challenge托管质询 这条规则会让所有访问这两个路径的流量先经过一个Cloudflare的JS挑战能过滤掉99%的自动化脚本。修改登录地址我安装了一个名为“WPS Hide Login”的轻量级插件将登录地址从/wp-login.php改为了一个随机的字符串路径比如/my-secret-login-door。这样之前的攻击脚本全部失效。启用Fail2ban我配置了Fail2ban来监控Nginx的访问日志自动封禁那些频繁访问不存在页面404和登录页的IP。第四阶段长期优化架构优化层全面启用缓存我检查并确保了Redis对象缓存插件正常运行将数据库查询命中率从30%提升到了95%。同时优化了CDN缓存规则将更多静态化页面如文章页、分类页缓存起来。考虑静态化因为这个站内容更新不频繁我开始评估将其迁移到Hugo静态生成器的可行性以从根本上杜绝此类PHP层面的攻击。整个处置过程大约花了2小时其中大部分时间在分析日志和验证规则效果。之后一周该站点再未出现类似的恶意流量高峰。4. 常见问题与排查技巧实录在实际操作中你肯定会遇到各种问题。下面是我总结的一些常见坑点和排查思路。Q1封禁IP后网站依然很慢CPU还是高。可能原因1攻击源IP已经更换或者使用了大量代理IP。你封禁的速度赶不上它更换的速度。排查再次分析最新日志看是否出现了新的IP段。使用iftop或nethogs命令查看实时的网络连接和带宽占用找出当前活跃的异常连接。解决从“封IP”转向“限频率”。立即启用Nginx的limit_req模块针对全站或特定路径进行速率限制。同时考虑启用Cloudflare的“Under Attack”模式或设置基于行为的WAF规则。Q2配置了Nginx限流limit_req但好像没效果。可能原因1配置作用域不对。limit_req指令需要放在http,server,location块中且limit_req_zone必须放在http块。检查你的配置语法和位置。可能原因2burst参数设置过大且没有nodelay。假设rate10r/sburst50没有nodelay。那么前50个超额请求会被放入队列延迟处理而不是立即拒绝这依然会占用服务器资源。在遭受攻击时建议使用nodelay。排查可以在Nginx日志格式中添加$limit_req_status变量查看每个请求的限流状态。log_format main ‘$remote_addr – $remote_user [$time_local] “$request” ‘ ‘$status $body_bytes_sent “$http_referer” ‘ ‘“$http_user_agent” “$http_x_forwarded_for” ‘ ‘“$limit_req_status”‘;然后查看日志如果看到大量PASSED以外的状态如DELAYED,REJECTED说明限流在起作用。Q3使用了Cloudflare但服务器真实IP被泄露攻击者绕过CDN直接攻击源站。可能原因这是非常常见且危险的问题。你的服务器可能通过其他方式暴露了IP例如邮件服务器使用了相同IP、网站代码中硬编码了服务器IP、通过某些在线工具查询到了历史解析记录等。解决严格隔离确保服务器上所有服务网站、邮件、数据库等都不直接暴露真实IP。可以为源站服务器再套一层防火墙安全组只允许Cloudflare的IP段访问你的80/443端口。Cloudflare官方公布了它的IP列表你需要定期更新防火墙规则。更换服务器IP如果IP已经暴露且持续被攻击最彻底的方法是更换服务器的公网IP地址。使用“源站屏蔽”在Cloudflare的SSL/TLS设置中将“加密模式”设置为“完全严格”并在源站服务器上安装并配置Cloudflare的Origin CA证书这样只有来自Cloudflare且携带有效证书的请求才能被源站接受。Q4误封了正常用户或搜索引擎蜘蛛如百度、Googlebot。预防在设置任何封禁或限流规则时务必为已知的友好爬虫和自身IP设置白名单。Nginx白名单示例# 定义白名单IP geo $whitelist { default 0; 1.2.3.4 1; # 你的办公室IP 8.8.8.8 1; # 示例实际需用搜索引擎官方IP段 } map $whitelist $limit { 0 $binary_remote_addr; 1 “”; } limit_req_zone $limit zoneperip:10m rate10r/s;Cloudflare防火墙规则创建一条规则当IP地址属于“已知爬虫”时跳过所有其他安全规则。补救定期检查被封禁的IP列表如iptables -L -n如果发现误封及时移除。对于Fail2ban可以查看/var/log/fail2ban.log并修改ignoreip配置项。Q5网站使用了WebSocket或API限流规则影响了正常功能。解决为特定的API路径或WebSocket连接路径设置独立的、更宽松的限流区域或者将其从全局限流中排除。location /api/ { # 为API设置独立的限流速率可以高一些 limit_req zoneapi_perip burst30 nodelay; # … API代理配置 } location /ws/ { # WebSocket连接可能不需要限流或者设置很宽松的限制 # limit_req zonews_perip burst50 nodelay; # … WebSocket代理配置 }处理恶意访问是一个持续对抗的过程。没有一劳永逸的方案核心在于建立监控-响应-加固的闭环习惯。开始的时候可能会觉得麻烦但当你配置好一套自动化工具如Fail2banCloudflare规则后日常维护成本会变得非常低。最重要的是保持冷静按照监控、分析、处置、加固的步骤来你的个人小站就能在绝大多数情况下保持安稳。
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
