先说说我遇到的一个真实场景。前两天给客户部署一套会员系统上线当天客户就反馈APP端登录不了网页后台正常。我远程一看网页确实没问题APP请求全部返回403页面上还带了一行带防火墙字样的提示。翻开宝塔Nginx防火墙的拦截日志发现APP登录接口被CC防护规则拦了原因很简单——APP启动后短时间内密集请求了登录、刷新、配置同步三个接口被判定成攻击行为。这不算新鲜事宝塔防火墙拦截正常请求的情况几乎每个业务上线后都会撞上几次。这篇就系统整理一下这类问题的排查思路和实操方案怎么确认是真拦截怎么把白名单加对以及如何调整防护策略让防火墙既能挡住真实攻击又不误伤正常业务。1. 先从原理层看清宝塔防火墙到底在拦什么很多人一遇到拦截就着急关防火墙这其实是下策。想解决问题先得弄明白你面对的防火墙是“哪一层”的以及它拦截的判定逻辑是什么。宝塔面板里的“防火墙”其实分为两套体系许多人混为一谈导致排查方向从一开始就是错的。1.1 面板里“两层防火墙”的本质区别第一层是系统级防火墙在Linux服务器上默认是Firewalld早期CentOS 6时代则是iptables。它工作在TCP/IP层只管端口、IP、协议不关心HTTP请求体里装的是什么。比如你在系统防火墙里放行了80和443端口那所有指向这两个端口的请求都能到达Nginx但到Nginx之后是否被处理它不管。第二层是Web应用防火墙宝塔默认集成在Nginx里的WAF模块通常是付费插件或某些版本的免费模块工作在最危险的HTTP应用层。它能看到你的完整URL、POST参数、Cookie、User-Agent、请求频率、来源地域然后基于一系列规则判断这个请求像不像攻击。宝塔WAF拦截后返回的错误码通常是403很多版本还会带“nginx-firewall”字样或者一个被拦截的提示页面。这两层的排查方法完全不同如果是系统防火墙拦截表现是连接直接超时、拒绝curl时没有HTTP响应头返回。如果是WAF拦截表现是能连通Nginx但返回403状态码同时拦截日志里有记录。我用一个比方来帮助理解系统防火墙等于小区门口的保安只认你的访客登记IP和端口WAF是写字楼里的闸机不仅要看你是谁还得看你手里拿的文件内容有没有问题。你辛辛苦苦配好了小区门禁结果写字楼闸机不认识你照样进不去。1.2 误拦截排名靠前的几个触发原因根据我处理过的几十个案例宝塔WAF误杀正常请求九成以上跑不出下面这几种情况。第一CC防护阈值设得太激进。宝塔的CC防护主要统计单个IP在单位时间内的请求次数如果阈值设得过低比如每60秒只允许30次那么任何正常客户端——尤其是APP、小程序、前端仪表盘这类会批量请求资源的应用——都可能被秒杀。第二URL或参数触发了危险特征词规则。WAF内置了大量基于正则规则的攻击样本比如路径里包含select、union、0x、eval、base64等容易和SQL注入或命令执行沾边的字符串就可能直接被拦。但业务上经常有人把广告词、加密串、版本号塞进URL参数里正好撞枪口。最典型的是某个API的key用了随机字符串碰巧拼出了规则特征。第三User-Agent太冷门或为空。移动端自定义WebView、POS机、智能硬件、Windows服务调用等场景下请求的User-Agent可能不包含常见浏览器特征WAF里的UA黑名单规则直接匹配“陌生UA”并拦截。有些硬件的UA甚至是一长串十六进制数字这在规则眼里简直“不是人发的”。第四地域限制或IP信誉误判。如果开了按地域封禁某些云厂商的出口IP、运营商大网NAT出口在GeoIP数据库里的归属可能和实际不符结果自己的员工、客户被当成“海外攻击者”封掉。这种情况我见过不止一次某江苏客户的宽带出口被识别到疑似跨省流量恰好触发封禁策略。第五回源IP识别错乱。这是上了CDN之后最容易踩的坑后面我会专门展开。服务器直接看到的客户端IP变成CDN节点IP如果开启了针对真实IP的封禁策略那么CDN节点IP或源站回源请求可能会触发各种奇怪问题。可以说WAF本身是一套“宁可错杀也不漏杀”的机制。它不认识你的业务只认识“协议特征”。理解到这一层后面所有配置动作才做得明白。2. 排查阶段先确认是真拦截再怀疑配置有问题走到配置白名单这一步之前必须先把问题定位准确。我建议按下面的顺序操作不要一上来就添加规则那样很可能白忙一场。2.1 三步判定法快速定位第一步用浏览器或者curl实际触发一次被拦截的请求观察返回状态码。如果页面内容是包含防火墙关键词的403拦截页基本可以确认是宝塔WAF如果是连接超时、ERR_CONNECTION_TIMED_OUT那要看系统防火墙或云平台安全组如果是502、504那跟防火墙没关系要看后端服务。第二步打开宝塔面板左侧“网站-防火墙”或“Nginx防火墙”的拦截日志按时间筛选出嫌疑IP。日志里会明确记录命中规则类型——是CC防护、URL规则还是UA规则这一点非常关键因为它直接告诉你要调哪个策略。日志里通常会有一条类似“拦截XX IP规则Custom Rule次数xx”的记录。第三步确认当前服务器网络链路中一共有几道过滤关口。云服务器往往有三层云厂商控制台的安全组、宝塔面板里的系统防火墙/安全插件、Nginx的WAF。我用过的腾讯云、阿里云服务器都遇到过安全组规则没有放行某个IP导致WAF不拦但连接也进不来的情况。所以当你发现WAF日志里没有记录但请求依然403或超时时去云控制台的安全组检查源IP限制往往一抓一个准。2.2 用一份测试文件快速区分层级这个技巧是我多年排查中总结的非常实用。在网站根目录放一个纯静态的测试文件路径比如/ping.html内容就写一个固定的字符串。然后让出问题的客户端去访问这个地址如果这个静态文件也访问不了说明拦截发生在Nginx外围或Nginx本身——排查系统防火墙、云安全组。如果静态文件能访问动态接口不行那焦点就全部放在WAF规则和接口路径上大概率是URL或者CC触发。通过这种“最小化请求”的方式可以把几十种可能性迅速缩小到一两个方向。2.3 临时关闭验证时的“安全姿势”很多时候需要临时关闭WAF来做对比实验以确认拦的就是它。但我不建议直接点“总开关”把所有防护关掉更稳妥的做法是首先给当前操作IP加上临时白名单然后在Nginx防火墙的设置中调整全局状态——先“关闭”再“打开”让配置重载一次。在低峰期操作观察2-3分钟即可。这个“先加白名单、再开开关”的顺序一定要注意因为如果你的包已经触发了某条规则且规则里开启了拦截加封禁IP那么在你关掉WAF后到下次重载之前Nginx里的Lua模块可能仍然保持着之前的封禁状态。实际操作中改完配置后建议重启Nginx或重载防火墙模块再请求验证。3. 实操白名单配置不同场景“对症下药”把问题确诊为“WAF误拦截”之后下面就是本文的重头戏——白名单到底应该怎么加。宝塔的Nginx防火墙设置面板里右侧导航有非常多的子项IP白名单、URL白名单、UA白名单、地域规则、CC防护、恶意UA拦截开关等。不少用户第一次打开一脸懵我把常用配置按场景拆开讲。3.1 IP白名单最直接但最容易被忽视细节前提场景你自己的出口IP比如公司固定IP、服务器本机IP、运维跳板机IP被拦或者某个合作方的服务器IP需要访问你的API。在“IP白名单”页面添加目标IP。这里有一个细节宝塔的白名单表单通常有两种模式一种填单个IP一种是IP段/CIDR。如果你只知道对方是一个出口范围可以使用CIDR形式例如114.114.114.0/24。还有一个经常踩的错误——使用IPv6网络时需要把IPv6地址也加进去否则照样被拦。IPv4和IPv6在白名单规则里不是自动通用的当前大多数面板在规则里默认IPv4如果客户端走IPv6匹配不上就会落回常规防护逻辑。添加备注是强烈建议。我见过太多人加白名单不写备注一个月之后忘了为什么加清理时也不知道谁在用只能放着积灰甚至误砍生产IP。备注至少包含三部分对方身份、用途、申请时间比如“供应商RPA回访接口 / 2025-04-12张三申请”。3.2 URL白名单处理回调、API误报的王牌如果你的被拦截请求有固定的路径前缀——例如支付宝支付回调/api/pay/notify、微信回调/api/wx/callback、第三方数据推送/push/receive——那么URL白名单比IP白名单更精准不会因为对方IP段漂移而失效。在宝塔的“URL白名单”中直接填写路径。注意规则匹配的是URL路径部分一般不含域名也不含query参数。例如填/api/pay/notify它匹配的是站点下一级路径的开头如果你想匹配某个目录下的所有内容路径写/api/pay/即可。有些版本的规则支持正则比如/callback/.但这个要谨慎写得越宽越容易放掉真正危险的请求。这里我特别说明一个最常见的误区URL白名单不是“域名白名单”。有人以为填了https://api.example.com/xxx就等于放行这个域名的所有请求实际上WAF过滤器只关注请求的URI部分与Host无关。如果你希望整个域名的请求都不走WAF逻辑上应该是为该域名单独关闭WAF或添加域名级的放行配置而不是写URL白名单。在我处理回调类接口的经验里加白名单的位置还有一个更隐蔽的入口有的误拦截请求是POST请求在URL里没有特征但在POST body里包含了某些字符串触发了WAF的参数过滤规则。这种情况下URL白名单“绕不过去”因为WAF的过滤机制是先读body再匹配规则路径不匹配照样解析。针对这类场景更稳妥的做法是调整触发拦截的具体规则或者把必要的参数在“全局参数过滤开关”中排除。3.3 UA白名单给“没见过的浏览器”一条生路很多桌面软件、终端设备在发起HTTP请求时User-Agent字段格式很特殊甚至直接留空。WAF规则里有一类就是针对恶意UA库来拦截的如果规则库收录了某个UA特征而恰好你的客户端用的UA与之相似就可能误拦截。反过来如果业务客户端的UA完全空白某些“非浏览器UA”过滤规则也可能中招。解决方案是在“UA白名单”中添加业务客户端的实际UA特征子串。注意脚本的匹配通常是“包含匹配”而非“全等匹配”所以填一段足够独特的子串即可比如MyBusinessApp/1.3。但这里有一个安全提醒UA白名单等于对伪造UA的攻击者敞开了大门所以不要把UA设成太通用的值比如Mozilla/5.0如果你确实在开发App建议在客户端代码里写一个带有产品标识的UA前缀然后在防火墙里只放行这个前缀。3.4 别忽略系统防火墙和云安全组的“外围白名单”前面已经提到过WAF层并不是单独存在。实际生产链路上的顺序通常是云安全组 - 服务器系统防火墙/Firewalld - Nginx - WAF模块 - PHP/Java后端。每一层都可能设防。我在宝塔面板的“安全”菜单中更新了防火墙放行端口但这只是系统Firewalld的规则如果云平台的“安全组”还在源IP限制层拦着你的合作方IP那么WAF层加多少白名单都起不了作用。所以当用户反馈外部系统怎么都访问不了你的接口时检查顺序建议是先在服务器上用curl从本机请求一次接口确认后端正常再让对端用telnet 你的IP 443测试端口连通性不通再去云控制台安全组确认源IP策略通了再去WAF日志里找拦截记录。这样一圈过滤下来问题定位很少会跑偏。4. 调整防护策略从“杀伐果断”到“张弛有度”白名单是治标的手段能救急但不能根本解决“规则配置不适配业务”的矛盾。一旦误拦截频发你需要回过去看整体防护策略是不是把WAF当成了“宁可错杀一千”的网关业务量本身不小但阈值却按“静态官网”标准配的防护等级是不是开得太高了下面结合常见的暴脾气的配置项一个个说。4.1 CC防护阈值先摸底再设置别靠猜宝塔WAF的CC防护分为全局和单站点两层按单IP在单位时间内的请求次数进行统计和惩罚。常见默认值可能是每60秒允许请求120次IP超过限制后自动封禁一段时间。对于一个在线商城页面用户浏览首页只要触发几十次资源请求图片、CSS、JS、接口这个级别其实够用。但APP启动时如果并发调了多个接口且每个接口又各自统计同一秒内就容易被追上。我处理过的一个实际案例是客户的后台管理系统允许管理人员批量导出Excel导出动作会并发生成几十个异步请求。结果管理员一点导出按钮瞬间触发CC阈值自己的IP被封禁10分钟。当时解决方案不是关闭CC而是先把阈值调整到业务高峰期实际请求量的3倍以上——带宽允许的前提下CC防护本来就是为了防脚本机器人不会说正常用户每秒20次的页面操作都扛不住。调优方法建议分两步走第一步先用工具压测你的核心接口得到单IP的峰值QPS第二步到宝塔WAF的“CC防护-全局设置”中将阈值设成实测峰值的2-3倍再把锁定的封禁时间从“永久”改成“5分钟”或“10分钟”进行观察。另外CC防护里往往还有“并发连接数”限制这个更容易误伤。如果你的服务端使用了WebSocket、长轮询或大文件分段上传连接数会长时间占用超过并发限制就会被拦截。建议这种场景直接手动调整并发数值或者将相关接口加入URL白名单并用其他策略保护。4.2 防护模式调到“合适档位”而不是“最高档”宝塔WAF提供多档防护级别有些版本叫“低、中、高”或“标准/严格”。对于同时在跑业务的服务我不建议长期使用最高档。高档防护意味着几乎每个请求都要做大量的规则正则匹配不仅增加CPU开销也更容易触发误杀。比较合理的配置是对静态资源目录/static、/upload、/public可以设置“不过滤”因为这些资源不存在SQL注入风险也不应该浪费算力去匹配规则。对动态接口开启中档规则并开启“恶意UA过滤”保留CC防护。对管理后台和上传接口单独加白名单并限定IP来源。这些策略分散在宝塔WAF的站点配置中建议每个站点单独调整不要全局一刀切。访问量大的站点和内部系统在规则选择上本来就不该相同。4.3 三种常见规则开关需要想清楚再动第一个是“过滤已知恶意IP”这个宝塔防火墙一般对接云端威胁情报库。如果开启后发生误拦查看拦截日志中是不是命中了情报库中的IP如果是合作方IP恰好被收录唯一的解决办法是加IP白名单同时向情报平台申诉。第二个是“恶意UA过滤”对于很多老系统、爬虫工具、支付接口UA不存在或UA来源于代码库里的默认值比如Go的Go-http-client/1.1、Java的Java/1.8.0_202就会命中过滤规则。如果你的系统存在这类正常的服务间调用开这个开关之前务必先看清楚调用方的UA。第三个是“URL关键词过滤”有些规则把路径里的JSON、CB、SDK等作为攻击签名拦截。如果确认业务回调路径被这种规则误伤可以临时禁用那条具体的规则但影响面较大。此时用URL白名单去做定向放行会更安全。4.4 上了CDN之后调防护策略时最容易忽略的一个坑只要你的域名走了CDN或云WAF源站Nginx拿到的客户端IP默认是CDN节点IP。这时候如果你在源站WAF里开启地域封禁那么封禁的其实不是真实用户IP而是CDN节点IP而CDN节点遍布全国甚至全球你很可能把“某个省的访问”误伤成“被拦截的海外流量”影响面会非常大。解决办法在宝塔面板中已经做了简化找到WAF设置里的“CDN”选项填入你所用的CDN厂商提供的回源IP段同时确认Nginx设置中能正确获取真实客户端IP。具体来说源站需要正确解析X-Forwarded-For或CDN-Src-Ip等请求头并将真实IP变量传给WAF模块。如果使用宝塔的默认Nginx配置但手动改过要小心没有加载set_real_ip_from和real_ip_header导致IP始终不对。加了CDN之后判断白名单是否生效不能只看自己本机IP最好的验证逻辑是临时在WAF中添加一个你的真实公网出口IP为白名单然后开启CDN回源访问接口。如果仍然被拦先看拦截日志里的客户端IP是什么是不是变成了CDN节点IP。一旦这种情况出现根源不是白名单没加对而是Nginx没有正确识别真实IPWAF看到的还是CDN节点。这时把CDN厂商的节点IP段和X-Forwarded-For头配置好让WAF日志里的IP回归成真实的客户端IP然后再来加白名单和调整策略才谈得上精准。5. 常见问题与排查技巧实录下面这些是群里和实际运维过程中高频出现的“疑难杂症”我把典型表现、排查思路和解决办法整理成了一份速查清单方便大家直接对着看。现象可能原因排查/解决办法已经加了IP白名单还是被拦截请求没经过WAF层之前还有云安全组拦截或Nginx没重载WAF模块仍保留旧的封禁缓存先检查拦截日志里显示的来源IP是不是目标IP再重载Nginx/防火墙同时检查云安全组源IP策略加白名单后需等待一会才生效面板更新规则写入文件但Nginx worker还在缓存在WAF设置里执行一次“重载规则”或重启Nginx生产环境选低峰期操作手机4G访问被拦同一WiFi正常运营商NAT出口IP变化或出口IP被归属到其他地区/命中恶意IP库查看日志中手机访问时的出口IP将其加白名单若频繁变化考虑业务侧支持固定在网/动态IP白名单方案APP客户端大量短时间访问被判CCCC阈值低于APP初始化并发请求峰值抓包统计APP启动时最大并发数上调CC阈值或将核心初始化接口加入URL白名单并用“签名参数”兜底CDN用户访问偶发403源站WAF封禁了CDN节点IP或地域策略错杀配置CDN真实IP透传确认日志显示客户端真实IP或临时关闭地域封禁观察POST请求体里包含“危险字符”触发规则WAF对参数内容做正则检测命中攻击签名在URL白名单中补充该接口或调整具体规则不建议直接关闭参数过滤管理后台只能自己IP访问其他人打不开加了“仅允许白名单IP访问”之类的访问控制开关检查防火墙站点级别是否开启了“仅白名单可访问”并把相关IP段加入白名单搜索引擎收录变少蜘蛛抓取被WAF拦了或UA规则误过滤了某些蜘蛛在UA白名单中放行百度、必应、Google等常用蜘蛛UA且不要开启恶意UA过滤的“空UA拦截”WAF规则更新后突然出现大面积拦截云端规则库升级后出现误报回滚到更新前版本如有或根据日志快速调整相关规则/加白名单这些案例中的绝大多数最后都归结为一个共同点规则或阈值的“默认值”不适合具体业务。防火墙不是配置完就能高枕无忧的而是需要在上线前、业务变更后、大促活动前反复迭代策略。6. 长期主义的防误拦建议解决问题的短暂爽快感之后还是需要建立一套长期维护机制避免每隔几个月就重演一遍“线上告警-排查-加白名单”的死循环。这里分享几个我在实际项目中养成的习惯不一定适合所有人但至少能帮你少走弯路。第一给所有规则做台账。你需要记录的内容是某条防火墙规则是谁加的、意图是什么、生效范围是什么、是否有过期时间。这个台账可以是宝塔面板自带的备注字段也可以是团队内部的一个Wiki表格。我在每台服务器上要求至少写清楚“谁/什么时间/为什么”三要素没有备注的白名单一律按临时规则处理季度清理时先提醒再移除。听起来麻烦但真的能救命——尤其是某天某条规则导致所有请求5秒超时你能立刻知道是哪条规则、什么时候引入的而不是依次禁用试探。第二上线前对关键API做一次“规则体检”。在你开发完接口、准备上线前先用一个代理或抓包工具抓取几种典型生产请求——包括GET、POST、上传、JSON体请求——然后逐一用Bearer令牌发起真实调用看有没有被WAF拦截。这一步我建议安排在联调阶段之前不要等到客户反馈后才填坑。第三合理利用“观察模式”或“日志模式”。部分付费版本宝塔WAF支持规则在“记录但不拦截”的模式下运行如果你的规则版本支持建议大版本规则更新后先观察1-2天确认无异常再切换为正式拦截模式。如果插件不支持也可以手动把某个核心接口临时加入白名单然后开启防护观察日志等没有误报后再从白名单中移除。第四把“误拦截”纳入告警策略。很多人等到客户打来电话才发现服务被拦了。更稳的姿势是通过宝塔的接口或读取Nginx的错误日志把403响应占比的异常升高纳入监控告警。没有监控体系的团队也可以用定时任务每10分钟扫一遍WAF拦截日志如果发现某个IP被反复拦截且匹配规则为CC立刻推送到钉钉或微信群。这个自动化处理方案写起来不复杂留到以后有机会单独出一篇脚本示例。第五定期审视是否还在用默认配置。我见过太多生产服务器从建站到现在防火墙的防护模式一直停留在面板初始默认从未因为业务变化而调整过。如果你手头有这样的服务器建议现在就花半小时完成一次配置体检确认当前防护级别、CC阈值、开关开关、白名单清单。毕竟防火墙是业务的看门人它的权限和策略越贴近真实流量你在深夜被吵醒的概率就越低。
先说说我遇到的一个真实场景。前两天给客户部署一套会员系统上线当天客户就反馈APP端登录不了网页后台正常。我远程一看网页确实没问题APP请求全部返回403页面上还带了一行带防火墙字样的提示。翻开宝塔Nginx防火墙的拦截日志发现APP登录接口被CC防护规则拦了原因很简单——APP启动后短时间内密集请求了登录、刷新、配置同步三个接口被判定成攻击行为。这不算新鲜事宝塔防火墙拦截正常请求的情况几乎每个业务上线后都会撞上几次。这篇就系统整理一下这类问题的排查思路和实操方案怎么确认是真拦截怎么把白名单加对以及如何调整防护策略让防火墙既能挡住真实攻击又不误伤正常业务。1. 先从原理层看清宝塔防火墙到底在拦什么很多人一遇到拦截就着急关防火墙这其实是下策。想解决问题先得弄明白你面对的防火墙是“哪一层”的以及它拦截的判定逻辑是什么。宝塔面板里的“防火墙”其实分为两套体系许多人混为一谈导致排查方向从一开始就是错的。1.1 面板里“两层防火墙”的本质区别第一层是系统级防火墙在Linux服务器上默认是Firewalld早期CentOS 6时代则是iptables。它工作在TCP/IP层只管端口、IP、协议不关心HTTP请求体里装的是什么。比如你在系统防火墙里放行了80和443端口那所有指向这两个端口的请求都能到达Nginx但到Nginx之后是否被处理它不管。第二层是Web应用防火墙宝塔默认集成在Nginx里的WAF模块通常是付费插件或某些版本的免费模块工作在最危险的HTTP应用层。它能看到你的完整URL、POST参数、Cookie、User-Agent、请求频率、来源地域然后基于一系列规则判断这个请求像不像攻击。宝塔WAF拦截后返回的错误码通常是403很多版本还会带“nginx-firewall”字样或者一个被拦截的提示页面。这两层的排查方法完全不同如果是系统防火墙拦截表现是连接直接超时、拒绝curl时没有HTTP响应头返回。如果是WAF拦截表现是能连通Nginx但返回403状态码同时拦截日志里有记录。我用一个比方来帮助理解系统防火墙等于小区门口的保安只认你的访客登记IP和端口WAF是写字楼里的闸机不仅要看你是谁还得看你手里拿的文件内容有没有问题。你辛辛苦苦配好了小区门禁结果写字楼闸机不认识你照样进不去。1.2 误拦截排名靠前的几个触发原因根据我处理过的几十个案例宝塔WAF误杀正常请求九成以上跑不出下面这几种情况。第一CC防护阈值设得太激进。宝塔的CC防护主要统计单个IP在单位时间内的请求次数如果阈值设得过低比如每60秒只允许30次那么任何正常客户端——尤其是APP、小程序、前端仪表盘这类会批量请求资源的应用——都可能被秒杀。第二URL或参数触发了危险特征词规则。WAF内置了大量基于正则规则的攻击样本比如路径里包含select、union、0x、eval、base64等容易和SQL注入或命令执行沾边的字符串就可能直接被拦。但业务上经常有人把广告词、加密串、版本号塞进URL参数里正好撞枪口。最典型的是某个API的key用了随机字符串碰巧拼出了规则特征。第三User-Agent太冷门或为空。移动端自定义WebView、POS机、智能硬件、Windows服务调用等场景下请求的User-Agent可能不包含常见浏览器特征WAF里的UA黑名单规则直接匹配“陌生UA”并拦截。有些硬件的UA甚至是一长串十六进制数字这在规则眼里简直“不是人发的”。第四地域限制或IP信誉误判。如果开了按地域封禁某些云厂商的出口IP、运营商大网NAT出口在GeoIP数据库里的归属可能和实际不符结果自己的员工、客户被当成“海外攻击者”封掉。这种情况我见过不止一次某江苏客户的宽带出口被识别到疑似跨省流量恰好触发封禁策略。第五回源IP识别错乱。这是上了CDN之后最容易踩的坑后面我会专门展开。服务器直接看到的客户端IP变成CDN节点IP如果开启了针对真实IP的封禁策略那么CDN节点IP或源站回源请求可能会触发各种奇怪问题。可以说WAF本身是一套“宁可错杀也不漏杀”的机制。它不认识你的业务只认识“协议特征”。理解到这一层后面所有配置动作才做得明白。2. 排查阶段先确认是真拦截再怀疑配置有问题走到配置白名单这一步之前必须先把问题定位准确。我建议按下面的顺序操作不要一上来就添加规则那样很可能白忙一场。2.1 三步判定法快速定位第一步用浏览器或者curl实际触发一次被拦截的请求观察返回状态码。如果页面内容是包含防火墙关键词的403拦截页基本可以确认是宝塔WAF如果是连接超时、ERR_CONNECTION_TIMED_OUT那要看系统防火墙或云平台安全组如果是502、504那跟防火墙没关系要看后端服务。第二步打开宝塔面板左侧“网站-防火墙”或“Nginx防火墙”的拦截日志按时间筛选出嫌疑IP。日志里会明确记录命中规则类型——是CC防护、URL规则还是UA规则这一点非常关键因为它直接告诉你要调哪个策略。日志里通常会有一条类似“拦截XX IP规则Custom Rule次数xx”的记录。第三步确认当前服务器网络链路中一共有几道过滤关口。云服务器往往有三层云厂商控制台的安全组、宝塔面板里的系统防火墙/安全插件、Nginx的WAF。我用过的腾讯云、阿里云服务器都遇到过安全组规则没有放行某个IP导致WAF不拦但连接也进不来的情况。所以当你发现WAF日志里没有记录但请求依然403或超时时去云控制台的安全组检查源IP限制往往一抓一个准。2.2 用一份测试文件快速区分层级这个技巧是我多年排查中总结的非常实用。在网站根目录放一个纯静态的测试文件路径比如/ping.html内容就写一个固定的字符串。然后让出问题的客户端去访问这个地址如果这个静态文件也访问不了说明拦截发生在Nginx外围或Nginx本身——排查系统防火墙、云安全组。如果静态文件能访问动态接口不行那焦点就全部放在WAF规则和接口路径上大概率是URL或者CC触发。通过这种“最小化请求”的方式可以把几十种可能性迅速缩小到一两个方向。2.3 临时关闭验证时的“安全姿势”很多时候需要临时关闭WAF来做对比实验以确认拦的就是它。但我不建议直接点“总开关”把所有防护关掉更稳妥的做法是首先给当前操作IP加上临时白名单然后在Nginx防火墙的设置中调整全局状态——先“关闭”再“打开”让配置重载一次。在低峰期操作观察2-3分钟即可。这个“先加白名单、再开开关”的顺序一定要注意因为如果你的包已经触发了某条规则且规则里开启了拦截加封禁IP那么在你关掉WAF后到下次重载之前Nginx里的Lua模块可能仍然保持着之前的封禁状态。实际操作中改完配置后建议重启Nginx或重载防火墙模块再请求验证。3. 实操白名单配置不同场景“对症下药”把问题确诊为“WAF误拦截”之后下面就是本文的重头戏——白名单到底应该怎么加。宝塔的Nginx防火墙设置面板里右侧导航有非常多的子项IP白名单、URL白名单、UA白名单、地域规则、CC防护、恶意UA拦截开关等。不少用户第一次打开一脸懵我把常用配置按场景拆开讲。3.1 IP白名单最直接但最容易被忽视细节前提场景你自己的出口IP比如公司固定IP、服务器本机IP、运维跳板机IP被拦或者某个合作方的服务器IP需要访问你的API。在“IP白名单”页面添加目标IP。这里有一个细节宝塔的白名单表单通常有两种模式一种填单个IP一种是IP段/CIDR。如果你只知道对方是一个出口范围可以使用CIDR形式例如114.114.114.0/24。还有一个经常踩的错误——使用IPv6网络时需要把IPv6地址也加进去否则照样被拦。IPv4和IPv6在白名单规则里不是自动通用的当前大多数面板在规则里默认IPv4如果客户端走IPv6匹配不上就会落回常规防护逻辑。添加备注是强烈建议。我见过太多人加白名单不写备注一个月之后忘了为什么加清理时也不知道谁在用只能放着积灰甚至误砍生产IP。备注至少包含三部分对方身份、用途、申请时间比如“供应商RPA回访接口 / 2025-04-12张三申请”。3.2 URL白名单处理回调、API误报的王牌如果你的被拦截请求有固定的路径前缀——例如支付宝支付回调/api/pay/notify、微信回调/api/wx/callback、第三方数据推送/push/receive——那么URL白名单比IP白名单更精准不会因为对方IP段漂移而失效。在宝塔的“URL白名单”中直接填写路径。注意规则匹配的是URL路径部分一般不含域名也不含query参数。例如填/api/pay/notify它匹配的是站点下一级路径的开头如果你想匹配某个目录下的所有内容路径写/api/pay/即可。有些版本的规则支持正则比如/callback/.但这个要谨慎写得越宽越容易放掉真正危险的请求。这里我特别说明一个最常见的误区URL白名单不是“域名白名单”。有人以为填了https://api.example.com/xxx就等于放行这个域名的所有请求实际上WAF过滤器只关注请求的URI部分与Host无关。如果你希望整个域名的请求都不走WAF逻辑上应该是为该域名单独关闭WAF或添加域名级的放行配置而不是写URL白名单。在我处理回调类接口的经验里加白名单的位置还有一个更隐蔽的入口有的误拦截请求是POST请求在URL里没有特征但在POST body里包含了某些字符串触发了WAF的参数过滤规则。这种情况下URL白名单“绕不过去”因为WAF的过滤机制是先读body再匹配规则路径不匹配照样解析。针对这类场景更稳妥的做法是调整触发拦截的具体规则或者把必要的参数在“全局参数过滤开关”中排除。3.3 UA白名单给“没见过的浏览器”一条生路很多桌面软件、终端设备在发起HTTP请求时User-Agent字段格式很特殊甚至直接留空。WAF规则里有一类就是针对恶意UA库来拦截的如果规则库收录了某个UA特征而恰好你的客户端用的UA与之相似就可能误拦截。反过来如果业务客户端的UA完全空白某些“非浏览器UA”过滤规则也可能中招。解决方案是在“UA白名单”中添加业务客户端的实际UA特征子串。注意脚本的匹配通常是“包含匹配”而非“全等匹配”所以填一段足够独特的子串即可比如MyBusinessApp/1.3。但这里有一个安全提醒UA白名单等于对伪造UA的攻击者敞开了大门所以不要把UA设成太通用的值比如Mozilla/5.0如果你确实在开发App建议在客户端代码里写一个带有产品标识的UA前缀然后在防火墙里只放行这个前缀。3.4 别忽略系统防火墙和云安全组的“外围白名单”前面已经提到过WAF层并不是单独存在。实际生产链路上的顺序通常是云安全组 - 服务器系统防火墙/Firewalld - Nginx - WAF模块 - PHP/Java后端。每一层都可能设防。我在宝塔面板的“安全”菜单中更新了防火墙放行端口但这只是系统Firewalld的规则如果云平台的“安全组”还在源IP限制层拦着你的合作方IP那么WAF层加多少白名单都起不了作用。所以当用户反馈外部系统怎么都访问不了你的接口时检查顺序建议是先在服务器上用curl从本机请求一次接口确认后端正常再让对端用telnet 你的IP 443测试端口连通性不通再去云控制台安全组确认源IP策略通了再去WAF日志里找拦截记录。这样一圈过滤下来问题定位很少会跑偏。4. 调整防护策略从“杀伐果断”到“张弛有度”白名单是治标的手段能救急但不能根本解决“规则配置不适配业务”的矛盾。一旦误拦截频发你需要回过去看整体防护策略是不是把WAF当成了“宁可错杀一千”的网关业务量本身不小但阈值却按“静态官网”标准配的防护等级是不是开得太高了下面结合常见的暴脾气的配置项一个个说。4.1 CC防护阈值先摸底再设置别靠猜宝塔WAF的CC防护分为全局和单站点两层按单IP在单位时间内的请求次数进行统计和惩罚。常见默认值可能是每60秒允许请求120次IP超过限制后自动封禁一段时间。对于一个在线商城页面用户浏览首页只要触发几十次资源请求图片、CSS、JS、接口这个级别其实够用。但APP启动时如果并发调了多个接口且每个接口又各自统计同一秒内就容易被追上。我处理过的一个实际案例是客户的后台管理系统允许管理人员批量导出Excel导出动作会并发生成几十个异步请求。结果管理员一点导出按钮瞬间触发CC阈值自己的IP被封禁10分钟。当时解决方案不是关闭CC而是先把阈值调整到业务高峰期实际请求量的3倍以上——带宽允许的前提下CC防护本来就是为了防脚本机器人不会说正常用户每秒20次的页面操作都扛不住。调优方法建议分两步走第一步先用工具压测你的核心接口得到单IP的峰值QPS第二步到宝塔WAF的“CC防护-全局设置”中将阈值设成实测峰值的2-3倍再把锁定的封禁时间从“永久”改成“5分钟”或“10分钟”进行观察。另外CC防护里往往还有“并发连接数”限制这个更容易误伤。如果你的服务端使用了WebSocket、长轮询或大文件分段上传连接数会长时间占用超过并发限制就会被拦截。建议这种场景直接手动调整并发数值或者将相关接口加入URL白名单并用其他策略保护。4.2 防护模式调到“合适档位”而不是“最高档”宝塔WAF提供多档防护级别有些版本叫“低、中、高”或“标准/严格”。对于同时在跑业务的服务我不建议长期使用最高档。高档防护意味着几乎每个请求都要做大量的规则正则匹配不仅增加CPU开销也更容易触发误杀。比较合理的配置是对静态资源目录/static、/upload、/public可以设置“不过滤”因为这些资源不存在SQL注入风险也不应该浪费算力去匹配规则。对动态接口开启中档规则并开启“恶意UA过滤”保留CC防护。对管理后台和上传接口单独加白名单并限定IP来源。这些策略分散在宝塔WAF的站点配置中建议每个站点单独调整不要全局一刀切。访问量大的站点和内部系统在规则选择上本来就不该相同。4.3 三种常见规则开关需要想清楚再动第一个是“过滤已知恶意IP”这个宝塔防火墙一般对接云端威胁情报库。如果开启后发生误拦查看拦截日志中是不是命中了情报库中的IP如果是合作方IP恰好被收录唯一的解决办法是加IP白名单同时向情报平台申诉。第二个是“恶意UA过滤”对于很多老系统、爬虫工具、支付接口UA不存在或UA来源于代码库里的默认值比如Go的Go-http-client/1.1、Java的Java/1.8.0_202就会命中过滤规则。如果你的系统存在这类正常的服务间调用开这个开关之前务必先看清楚调用方的UA。第三个是“URL关键词过滤”有些规则把路径里的JSON、CB、SDK等作为攻击签名拦截。如果确认业务回调路径被这种规则误伤可以临时禁用那条具体的规则但影响面较大。此时用URL白名单去做定向放行会更安全。4.4 上了CDN之后调防护策略时最容易忽略的一个坑只要你的域名走了CDN或云WAF源站Nginx拿到的客户端IP默认是CDN节点IP。这时候如果你在源站WAF里开启地域封禁那么封禁的其实不是真实用户IP而是CDN节点IP而CDN节点遍布全国甚至全球你很可能把“某个省的访问”误伤成“被拦截的海外流量”影响面会非常大。解决办法在宝塔面板中已经做了简化找到WAF设置里的“CDN”选项填入你所用的CDN厂商提供的回源IP段同时确认Nginx设置中能正确获取真实客户端IP。具体来说源站需要正确解析X-Forwarded-For或CDN-Src-Ip等请求头并将真实IP变量传给WAF模块。如果使用宝塔的默认Nginx配置但手动改过要小心没有加载set_real_ip_from和real_ip_header导致IP始终不对。加了CDN之后判断白名单是否生效不能只看自己本机IP最好的验证逻辑是临时在WAF中添加一个你的真实公网出口IP为白名单然后开启CDN回源访问接口。如果仍然被拦先看拦截日志里的客户端IP是什么是不是变成了CDN节点IP。一旦这种情况出现根源不是白名单没加对而是Nginx没有正确识别真实IPWAF看到的还是CDN节点。这时把CDN厂商的节点IP段和X-Forwarded-For头配置好让WAF日志里的IP回归成真实的客户端IP然后再来加白名单和调整策略才谈得上精准。5. 常见问题与排查技巧实录下面这些是群里和实际运维过程中高频出现的“疑难杂症”我把典型表现、排查思路和解决办法整理成了一份速查清单方便大家直接对着看。现象可能原因排查/解决办法已经加了IP白名单还是被拦截请求没经过WAF层之前还有云安全组拦截或Nginx没重载WAF模块仍保留旧的封禁缓存先检查拦截日志里显示的来源IP是不是目标IP再重载Nginx/防火墙同时检查云安全组源IP策略加白名单后需等待一会才生效面板更新规则写入文件但Nginx worker还在缓存在WAF设置里执行一次“重载规则”或重启Nginx生产环境选低峰期操作手机4G访问被拦同一WiFi正常运营商NAT出口IP变化或出口IP被归属到其他地区/命中恶意IP库查看日志中手机访问时的出口IP将其加白名单若频繁变化考虑业务侧支持固定在网/动态IP白名单方案APP客户端大量短时间访问被判CCCC阈值低于APP初始化并发请求峰值抓包统计APP启动时最大并发数上调CC阈值或将核心初始化接口加入URL白名单并用“签名参数”兜底CDN用户访问偶发403源站WAF封禁了CDN节点IP或地域策略错杀配置CDN真实IP透传确认日志显示客户端真实IP或临时关闭地域封禁观察POST请求体里包含“危险字符”触发规则WAF对参数内容做正则检测命中攻击签名在URL白名单中补充该接口或调整具体规则不建议直接关闭参数过滤管理后台只能自己IP访问其他人打不开加了“仅允许白名单IP访问”之类的访问控制开关检查防火墙站点级别是否开启了“仅白名单可访问”并把相关IP段加入白名单搜索引擎收录变少蜘蛛抓取被WAF拦了或UA规则误过滤了某些蜘蛛在UA白名单中放行百度、必应、Google等常用蜘蛛UA且不要开启恶意UA过滤的“空UA拦截”WAF规则更新后突然出现大面积拦截云端规则库升级后出现误报回滚到更新前版本如有或根据日志快速调整相关规则/加白名单这些案例中的绝大多数最后都归结为一个共同点规则或阈值的“默认值”不适合具体业务。防火墙不是配置完就能高枕无忧的而是需要在上线前、业务变更后、大促活动前反复迭代策略。6. 长期主义的防误拦建议解决问题的短暂爽快感之后还是需要建立一套长期维护机制避免每隔几个月就重演一遍“线上告警-排查-加白名单”的死循环。这里分享几个我在实际项目中养成的习惯不一定适合所有人但至少能帮你少走弯路。第一给所有规则做台账。你需要记录的内容是某条防火墙规则是谁加的、意图是什么、生效范围是什么、是否有过期时间。这个台账可以是宝塔面板自带的备注字段也可以是团队内部的一个Wiki表格。我在每台服务器上要求至少写清楚“谁/什么时间/为什么”三要素没有备注的白名单一律按临时规则处理季度清理时先提醒再移除。听起来麻烦但真的能救命——尤其是某天某条规则导致所有请求5秒超时你能立刻知道是哪条规则、什么时候引入的而不是依次禁用试探。第二上线前对关键API做一次“规则体检”。在你开发完接口、准备上线前先用一个代理或抓包工具抓取几种典型生产请求——包括GET、POST、上传、JSON体请求——然后逐一用Bearer令牌发起真实调用看有没有被WAF拦截。这一步我建议安排在联调阶段之前不要等到客户反馈后才填坑。第三合理利用“观察模式”或“日志模式”。部分付费版本宝塔WAF支持规则在“记录但不拦截”的模式下运行如果你的规则版本支持建议大版本规则更新后先观察1-2天确认无异常再切换为正式拦截模式。如果插件不支持也可以手动把某个核心接口临时加入白名单然后开启防护观察日志等没有误报后再从白名单中移除。第四把“误拦截”纳入告警策略。很多人等到客户打来电话才发现服务被拦了。更稳的姿势是通过宝塔的接口或读取Nginx的错误日志把403响应占比的异常升高纳入监控告警。没有监控体系的团队也可以用定时任务每10分钟扫一遍WAF拦截日志如果发现某个IP被反复拦截且匹配规则为CC立刻推送到钉钉或微信群。这个自动化处理方案写起来不复杂留到以后有机会单独出一篇脚本示例。第五定期审视是否还在用默认配置。我见过太多生产服务器从建站到现在防火墙的防护模式一直停留在面板初始默认从未因为业务变化而调整过。如果你手头有这样的服务器建议现在就花半小时完成一次配置体检确认当前防护级别、CC阈值、开关开关、白名单清单。毕竟防火墙是业务的看门人它的权限和策略越贴近真实流量你在深夜被吵醒的概率就越低。
