说实话当监控大屏上连续一周飘红清一色来自广东的IP还在以每小时几十万次请求的节奏打向视频调度接口时我第一反应是CDN回源配置出了问题。查完日志才发现根本不是误配置这些请求的User-Agent里齐齐整整带着gdhg-cw5100URL全是internet_r_vid前缀像是某个PCDN盒子在玩了命地预取视频流。后面做了UA封禁、封IP段、限频效果都撑不过三天第周一早照样被打满。这个场景相信做过视频、直播、下载类业务运维的朋友都不陌生。广东IP、PCDN刷量、流量劫持这三件事搅在一起几乎成了“难根治”的代名词。单纯封IP是堵不住洪水的因为对方手里握着的是一整片家宽出口池今天封了明天换个地址继续来。这篇文章我想把整个问题的底牌摊开讲清楚为什么PCDN刷量能持续这么久、请求特征里藏着哪些信息、JA3/JA4指纹到底能派上什么用场以及一套我实际跑过、真能压住量的三层防护方案。不管你手里是自建源站还是用的云厂商CDN这套思路都值得抄作业。1. 为什么广东IP刷量是个“老大难”PCDN流量劫持的底层逻辑1.1 PCDN盒子的刷量动机从哪来的PCDN的初衷其实挺朴素把CDN的带宽成本从机房下沉到用户家里通过智能路由器、电视盒子、光猫这类设备让用户贡献上行带宽和缓存能力帮助内容厂商省骨干网流量费。为了激励用户插着不拔电厂商通常会按“贡献的流量”给收益于是这玩意儿就有了被薅的空间。有收益机制就有刷量的土壤。灰产手里控制着一批盒子很多是二手回收的机顶盒、刷过固件的智能路由去伪造调度的“CDN预取请求”或者高频拉取视频分片来制造“这个节点确实有人在大量下载”的假象。从业务侧看这些请求完全合法它就是正常的HTTP请求带的UA、Cookie、协议头都是真设备能说出来的话。真正的麻烦在于刷量方和被劫持的真实用户混在同一个出口里你没法把一个IP上的流量一股脑全干掉否则误杀率会直接爆炸。广东在这个问题上格外扎眼有它的客观原因。广东是广电宽带和运营商融合套餐渗透率极高的省份家宽覆盖密度大出口NAT池大一两千万家庭用户背后对应的IPv4地址可能就集中在若干个大段里。灰产发现了这个规律住宅IP的“信誉分”天然比机房IP高IDS、WAF对这些段往往放了很宽的口子于是更愿意把伪造流量藏在这些出口后面。日志里那个gdhg-cw5100我按设备型号和地域分布查过极大概率是广东广电体系里某个融合套餐附带的终端型号——它本身是存量很大的正规格设备但在特定批次里被批量塞了异常逻辑或者被外部手段改了行为。这就是“广东IP”和“PCDN刷量”被绑在一起的核心原因资源池大、出口信誉高、同一型号设备基数大灰产可用的“马甲”多到数不清。1.2 流量劫持最常见的三种注入路径要防住这种攻击光看“坏流量”本身是不够的你得知道这些坏流量是怎么混进来的。我拆了抓包和日志后把路径归纳成三类第一类固件与SDK侧注入。盒子固件被二次打包植入了一套额外的调度逻辑开机就自动向源站发起大量预取请求。这种请求的UA、TLS指纹往往和原厂SDK一模一样你要防只能从行为上看出它“不像正常用户”。第二类网络侧NAT/CGNAT汇聚。运营商给家宽用户做地址转换一个公网出口IP背后可能挂着几十上百户人家。灰产通过网络侧的劫持或中间层控制把自己的请求混进这个NAT池里。你在服务端看到的是一个“正常住宅IP”实际发请求的却根本不是那个住户。第三类应用层伪装。把UA改成主流播放器版本模仿视频SDK的请求间隔还带上了有效的Referer和业务参数。这类请求从Header层看几乎无法区分只有深入到TLS握手细节和行为统计才能露出马脚。为什么“封IP”治标不治本因为这三条路径的共同特点就是地址不可锚定。IP会复用、会漂移、会轮换今天锁定的段明天可能让渡给真实用户了。你封得越狠误伤真实用户的概率越高投诉就跟着来。这也是我从一开始就不建议纯靠封IP硬干的原因——必须找到比“地址”更稳定的特征。2. 别急着封IP先把手头流量特征拆干净2.1 从UA与URL丝线里看出门道gdhg-cw5100 与 internet_r_vid任何防护方案启动之前第一步永远是“画像”。画像不是靠猜是从真实日志里把共性特征捞出来。我当时随手awk了一下Nginx访问日志发现攻击请求的规律极其明显UA里几乎都含gdhg-cw5100这个设备型号串有的版本号在Build后面有细微差异但主串稳定URL路径都以/internet_r_vid/开头后面跟着的是规律性的分片ID请求间隔异常规整几乎以固定频率触发像定时任务一样每秒几次单IP的单日请求量是正常用户的几十倍到上百倍。这个internet_r_vid很有意思vid大概率是video id的缩写r可能是real/relay/range一类的缩写结合路径上的分片序列这就是典型的视频预取/调度行为。正常用户看视频时也确实会请求这个路径但正常人的请求密度是“看到哪、拉到哪”而刷量请求是“不管你看不看先把全片拉完”。所以第一步特别简单把日志按UA、URL前缀、时间序列做三个维度的聚合看看有没有“扎堆”现象。当某个UA的请求量占到全站请求的30%以上而且请求目标集中在一类URL前缀时你基本可以确定这是机器行为而不是用户行为。聚合脚本不复杂Python加pandas十分钟就能跑完。2.2 从IP属性验证“这是不是一伙的”光看UA还不够因为对方随时会换UA。第二步是给请求IP做“出身核查”。我习惯把IP信息拉下来做四件事查ASN归属、查IP类型家宽/IDC/政企、查是否NAT出口池、查地域分布。这里要注意别只看“广东”这个省名要看城市粒度甚至区级粒度攻击段往往会集中在一个运营商的一个地市出口里。以这次为例把攻击IP聚合后发现它们绝大多数落在广东广电体系的家宽NAT段ASN是广电网络的自治域IP类型标记为住宅/广电融合套餐。这个信息最大的价值是它帮我把“策略杀伤范围”从全网缩小到了一个特定运营商特定地域特定设备型号的交集里。在这个交集内做限制误杀面可控出了这个交集我根本不动它。我现在的工作流里IP属性核查已经常态化跑批脚本挂在每小时的定时任务上自动更新“涉事IP段”列表。这样做的好处是即使对方换了新的IP只要它还藏在这个广电NAT池体系里我的信誉评分会立刻把它归入“高风险池”虽然还没法直接封禁但行为层阈值会显著收紧。2.3 两个小时的日志采样法有读者问过我“怎么才能确认这些请求是攻击而不是某一款App的合法预取逻辑”我的回答是单看流量不行要把请求特征和业务场景对照起来看。我建议按下面这个流程做一次“两小时采样”完全够用取最近两小时的访问日志去掉静态资源只留调度、播放、预取类接口按UA聚合列出Top 20 UA的请求量、独立IP数、平均请求间隔对Top UA样本随机抽50个IP查ASN归属和IP类型看这些请求的成功率、重试率、请求分片是否按顺序、是否短时间内请求了超长视频把结论和业务侧确认正常用户会不会在两小时内把一个2小时长片的几千个分片全部拉完。我们当时的结论非常明确一个正常用户一夜最多看3部电影而这些设备在半夜3点以毫秒级间隔把几十部影片的分片全量拉了一遍成功率还接近100%。这就不是用户是收割机。做完这个采样你已经有了“该拦谁”的名单下一步才是选工具。3. JA3/JA4指纹从“看IP”进化到“看握手”3.1 应用层封禁为什么反复失效把UA和IP封掉之后我经验里最经典的场面就是第一天立竿见影第二天回落一半第三天全面反弹。原因不复杂——UA可以随机生成X-Forwarded-For可以随便填Header能伪造的字段太多了对方只需要把UA字符串换成另一台“合法设备”的UA你的规则就成了废纸。而且这里有个技术现实的坑HTTP协议本身是明文可伪装的你从应用层看到的任何关于“身份”的信息都是对方想让你看到的。Cookie是服务端发的可以防篡改但对于没有登录态的匿名流量你没有Cookie可用。IP又是动态池。结果就是在到达“TLS握手”之前你手里根本没有一个能稳定区分“这请求出自什么客户端实现”的锚点。3.2 JA3与JA4的原理拆解TLS握手是明文建立连接的第一步客户端在ClientHello消息里会宣告自己支持的密码套件、扩展列表、椭圆曲线、版本号等参数。这些参数组合起来天然就是客户端实现的一个指纹。JA3的核心思路就是把这五个要素拼成字符串再取一个MD5JA3 MD5(SSLVersion, CipherSuites, Extensions, EllipticCurves, EllipticCurvePointFormat)同一家SDK、同一个系统的TLS栈JA3指纹几乎一致而灰产用的golang、curl、Python requests、自定义抓包工具和正规浏览器的TLS参数组合差异巨大这就给了识别空间。现实中我见过最明显的例子刷量流量里大量指纹落在curl和Go-http-client上而正常广电盒子的播放器SDK指纹是固定的一条。当某个“盒子的业务流量”却带上了编程语言的TLS指纹这不是劫持是什么JA4是JA3的演进版我在生产环境里更推荐它。JA3有个硬伤它把所有扩展原样拼接再取哈希只要对端随便调整了一下扩展顺序、加了一个无关插件指纹就变了稳定性差。JA4做了结构化处理把TLS请求按“协议版本 快照长度 扩展粗分类/TLS特征 扩展顺序 密码套件粗分类/密码套件顺序”分层计算再把前几个决定“客户端类型差异”的字段暴露出最后对部分字段取哈希。翻译成人话就是JA4能容忍“无关痛痒的微调”但对“换了实现”极度敏感。灰产想绕过JA4远比改个UA难得多。3.3 指纹从哪来采集端与计算端的设计讲完原理说落地。JA3/JA4的采集点有两个选择一是旁路镜像流量用抓包工具解析TLS握手优点是源站代码零改动缺点是你得维护一套额外的采集链路。二是前置网关内直接取比如Nginx/OpenResty在ssl_certificate_by_lua阶段读取ClientHello数据实时算出指纹和业务请求日志一起落盘。生产里我推荐后者延迟低、部署简单还能在Nginx层直接做决策。OpenResty取ClientHello的代码思路大致是这样-- 在ssl_certificate_by_lua_block阶段执行此时客户端已发送ClientHello但连接尚未完成握手 local ssl require ngx.ssl local ok, err ssl.clear_certs() if not ok then return ngx.exit(ngx.ERROR) end -- 通过ngx.ssl的clienthello接口拿到各字段 -- 然后自行拼接计算JA3/JA4也可以直接调用lua-resty-ja3这类现成库 local ja3, ja4 compute_fingerprint()这里要特别注意ssl_certificate_by_lua阶段的代码执行得越短越好因为这个阶段太靠前一旦出错就会断掉整个TLS握手。所以我的习惯是计算完指纹立刻打上请求头标记不做任何复杂逻辑或数据库查询真正的判定放到access阶段再干。计算完的指纹随日志转发到ClickHouse或者Elasticsearch里存着后续离线分析、聚类、建信誉库都用它。4. 精准防护落地方案识别、验证、限制三步走4.1 三条防线协同指纹信誉 IP信誉 行为频控等指纹数据攒了几天你会看到攻击侧和正常侧的指纹分布出现两个极端聚类。这时就可以上“三层防线”了。我把这三层分别定义成防线输入作用优点指纹信誉JA3/JA4命中库内黑指纹快速拦截已知恶意客户端实现不受IP漂移影响精准打击IP信誉出口ASN、IP类型、历史命中率对特定风险段收紧阈值能覆盖未知指纹的漏网流量行为频控单IP/单指纹请求速率、并发数拦截规则内的突发兜底能力最强防止特征突变实际执行的顺序是先看指纹是否命中“高危指纹”名单命中就直接拒绝指纹干净但IP落在“风险池”里的走行为频控把速率阈值调到正常用户的五分之一指纹、IP都正常但单IP请求速率异常高的临时限速而不是封禁防止误杀。这套组合拳的好处在于即使指纹被对方换掉IP信誉能补位即使IP被对方换掉指纹能补位两个都被绕了行为频控还在兜底。三条线互相兜底是方案能持续稳定几周的核心原因。4.2 用OpenResty写一个可运行的决策流我把OpenResty的决策流写成了一个轻量但完整的模板你可以直接抄过去改参数-- access_by_lua_block阶段执行 local resty_limit_req require resty.limit.req local lim, err resty_limit_req.new(req_rate, 20, 5) if not lim then return ngx.exit(ngx.ERROR) end local client_ip ngx.var.remote_addr local ja3 ngx.var.http_x_ja3 or -- 从握手阶段打标的Header取指纹 local ip_risk is_risk_ip(client_ip) -- 查内存字典或redis判断IP信誉 local fg_risk is_risk_fingerprint(ja3) -- 查指纹黑名单 if fg_risk then ngx.log(ngx.WARN, blocked by fingerprint: , ja3, , ip: , client_ip) return ngx.exit(403) end if ip_risk and lim:take( burst_ .. client_ip, 0 ) nil then ngx.exit(503) end -- 风险IP的速率阈值20次/秒正常用户为100次/秒 if ip_risk then local delay, err lim:take( risk_ .. client_ip, 0 ) if delay or err then return ngx.exit(503) end end这里的核心变量是两个指纹黑名单和IP风险字典。指纹黑名单我建议用hash表灌进共享内存配合每五分钟一次的更新任务同步保证查询在微秒级完成。IP风险字典可以用Redis的hash或者resty.memcached缓存注意设好过期时间。整个判定链路上关键的技巧就是让“高风险但未确认恶意”的流量先走限速而不是拒绝尽可能避免误杀。它把用户确实慢了一点但不至于打不开。4.3 灰度策略和误杀红线防御方案最怕的是什么不是防不住是误杀。把正常用户的播放器流量当成刷量拦了投诉和舆情分分钟压过来。所以我在上线这套方案时坚持做了灰度第一周只采集指纹不做拦截把每一类指纹和它的请求行为记录到日志离线核对哪些指纹在攻击流量里占比超过80%、在正常流量里低于0.1%第二周开放“观察模式”命中高危指纹的请求返回正常业务响应但打上标记每天的日志做二次人工抽验第三周对精确命中并且抽验无误的指纹开启拦截拦截比例先设1%确认无误后逐步上调到10%、50%、100%。同时设了几条死规矩任何一条新指纹要进黑名单必须满足“攻击流量占比95%且正常流量占比0.5%”的双条件封禁默认有效期为24小时到期自动转观察对VIP用户、付费会员的出口段一律只限速不封禁监控指标里除了“攻击拦截量”还得盯“正常用户错误率”一旦正常错误率上升超过0.5个百分点立刻回滚。这套红线帮我躲了至少三次可能酿成事故的误杀。5. 常见问题与排查技巧实录5.1 一张表看清五个高频坑这套方案跑起来之后真正的问题往往不在“挡没挡住”而在“有没有挡错”。我把遇到的五个高频坑总结成了下面这张表按出现频率排序问题现象排查方向解法真实用户被误杀某个主播或重度用户视频突然卡顿看被拦截的IP是否落在广电NAT大池、请求里是否有正常的业务参数对正常业务参数放行、降低行为阈值敏感度刷量方更换TLS实现JA3黑名单命中量骤降但请求量没降对比JA4是否命中、行为层是否触发限速升级JA4指纹判定同时收紧IP池的行为阈值出口IP漂移昨天的风险IP今天变成正常用户IP信誉库跟不上变化缩短IP信誉缓存时间加入IPv6 CIDR前缀匹配回源流量被误判源站向CDN回源时带了固定UA和固定IP回源IP段与家庭宽带结构完全不同特征明显回源IP加白不参与指纹和频控判定指纹与UA一半一半混着来刷量流量既有旧UA也有新UA对方在灰度替换客户端新旧同时运作指纹和IP策略分开维护互不依赖防止换一个漏一个5.2 排查时我最常用的三条路子第一离线聚类永远比在线拍脑袋靠谱。遇到任何可疑流量先拉一周的日志用IP、UA、JA3/JA4、请求路径四个维度做聚类看能不能聚出一个“行为一致的团伙”。如果某类指纹在攻击时段出现率90%、正常时段出现率0%那就可以直接进黑名单。第二给指纹设置信度不要做非黑即白的判断。一个JA4指纹出现在正常流量里的比例超过5%我就不建议直接拦截而是把它放入“观察名单”。观察名单的作用不是拦是让你能看到它的行为轨迹等数据够了再升级。这个思路帮我避免了很多因为浏览器指纹版本迭代产生的误杀。第三日志留痕要够长。很多团队排查故障时才后悔日志只留三天。我在做这套方案时把所有TLS指纹、IP、UA、请求路径、返回码都写进了ClickHouse保留90天。这样即使过了两个月对方突然变招我也能回溯到最开始出现的那个时间点对比变化前后的流量差异快速定位新特征。6. 题外话为何说“根治”是个伪命题我先把话说透只要PCDN还有商业激励刷量就不会从物理上消失。你看到的是“广东IP持续刷量”本质上是一套有成本收益的生意在支撑着它——伪造流量的成本低、收益高被发现的代价又小。你做得再绝对方无非是换一批更隐蔽的工具、再换一批出口和你继续耗。所以真正务实的预期不是“根治”而是把对方单次攻击的成本抬到高于收益让对方觉得这个项目不值得再投入。我自己的体会是这套JA3/JA4加IP信誉加行为频控的组合方案最大的价值不是某一条规则有多准而是它让攻击方需要同时对抗三套互相独立、又互相验证的识别机制绕过成本翻了几个数量级。我这边跑了一个半月后刷量请求量从峰值每小时几百万降到了零星几百虽然偶尔还有漏网的但已经不影响业务曲线和结算数据了。如果你正在被类似的“IP刷量”折磨我的建议是别急着封IP、别急着买昂贵的WAF套餐先把日志翻开看清楚再用TLS指纹做一轮画像你会看到一个和传统“抓UA、抓IP”完全不同的清晰世界。另外提醒一句任何从TLS握手阶段提取的指纹类技术都要顺手记录审计日志万一对方扯皮或误伤纠纷时你有据可查。技术防护只是第一条线留痕、摆数据、能解释清楚才是让方案长期跑下去的真正底气。