打开F12，防范切到Application面板，防范看Cookie里那个叫BIGipServerxxx的防范键值。这就是防范F5负载均衡器留给你的第一道痕迹。很多做数据采集的防范人盯着User-Agent和Referer改来改去，却不知道F5在Cookie里直接塞了后端真实服务器的防范IP和端口。编码方式简单到令人发指——把IP和端口按位运算后拼成一个十进制数，防范再转成十六进制字符串。防范
我去年帮一个做电商比价的防范团队排查问题。他们用轮换代理池请求某平台，防范响应时快时慢，防范偶尔返回登录页。防范抓包看了半天，防范发现每次请求带上的防范Cookie里都有个BIGipServerpool_web的字段。解码后，防范后端服务器IP是10.0.3.47，端口8080。他们代理池换了，但F5通过这个Cookie把请求粘滞到了同一台后端机。更麻烦的是，这台机器负载已经很高，响应自然慢。而登录页的出现，是因为那台后端机的session已经过期，F5却还在往那儿送。
F5的Cookie编码规则不复杂。以BIGipServer开头的键，值通常形如“1677787402.36895.0000”。第一段是IP的十进制表示，第二段是端口。算法是：IP的四个八位组分别乘以256的幂次再求和，端口则是直接取整。比如10.0.3.47，计算为10*256³ + 0*256² + 3*256 + 47 = 1677787402。端口8080对应36895？不对，8080的十六进制是1F90，但F5用的是端口乘以256再加偏移？实际是端口直接转十进制，但这里36895是0x901F，小端序。所以解码时要反过来：取低16位再交换字节序。这个细节坑过很多人。
防范思路分两层。如果你只是不想被粘滞，每次请求前把BIGipServer*的Cookie删掉。F5发现没有这个Cookie，会重新做负载均衡，可能把你分配到空闲的后端。但注意，有些F5配置了“Insert Cookie”模式，你删了它下次响应还会塞回来。这时候得在客户端拦截Set-Cookie头，或者用无Cookie的会话保持方式。
更深一层，如果你要获取真实后端IP做分析，那就主动解码。Python里几行代码的事：取Cookie值，按点分割，第一段转整数，再转成IP字符串。第二段端口做字节序转换。拿到IP后，你可以直接请求那台后端机，绕过F5。但别高兴太早——很多环境里后端机只监听内网，你从外网根本连不上。这时候解码出来的IP只能用来判断F5的调度策略，比如是不是按源IP哈希，还是轮询。
有个坑我踩过。某次解码出一个192.168.1.100，以为是内网地址，结果那台F5做了SNAT，后端看到的源IP是F5自己的。你拿到的“真实IP”其实是F5的VIP映射后的地址。验证方法：同时请求两次，如果BIGipServer值不变，说明会话保持生效；如果变了，说明是轮询或最小连接。再结合响应时间，能大致推断后端负载。
最后说个野路子。有些F5会暴露X-Forwarded-For头，但优先级低于Cookie。你可以同时检查这两个来源。如果Cookie里没有BIGipServer，但XFF有多个IP，取第一个非内网地址。不过XFF可以被伪造，Cookie相对难改——因为F5会校验Cookie的完整性，改了值可能直接返回400。所以解码Cookie比改XFF靠谱。
实际对抗中，别只盯着Cookie。F5还会在响应头里留X-WA-Info、X-Cnection之类的字段。多抓几次包，对比不同请求的差异，比死记编码规则管用。我习惯用Burp的插件自动解码BIGipServer，省得每次手算。工具能解决的事，别硬扛。