简介burpFakeIP-master.zip 是一款面向 Web 安全测试人员的 Burp Suite 插件资源包用于在渗透测试或授权评估中模拟不同源 IP 地址规避基于 IP 的访问限制同时保护测试者身份。该插件基于 Python 编写核心代码为 fakeIP.py配合 README.md 说明文档可快速了解配置方式包内 12 个文件以 9 张 png 截图为主直观展示插件界面与配置步骤另有 test.txt 用于测试验证。压缩包整体仅 1.09MB轻量易部署适合 Burp Suite 的初中级使用者扩展工具链。已有 412 人学习下载资源来自 GitHub 开源项目包含完整插件源码、使用说明和效果截图读者可据此理解 IP 伪装实现思路并直接导入扩展使用提升测试隐蔽性与多场景模拟能力。1. burpFakeIP 是什么一个让测试请求“换头”的 Burp 扩展从 burpFakeIP-master.zip 这个包名就能猜到这是一个针对 Burp Suite 的扩展核心能力是给发出去的请求批量伪造或随机化 IP 头。做接口测试、越权测试、风控调试的人经常会遇到一个问题服务端根据来源 IP 做限制而测试机 IP 只有一个很多场景复现不出来。比如登录接口有同 IP 限流或者某个接口只有特定网段才能访问手动在 Proxy 里改 X-Forwarded-For 又慢又容易漏。这个扩展就是把这些操作自动化让你在 Burp 里像开关一样控制请求头里的 IP 信息。适合授权范围内的安全测试、开发阶段联调、线上问题复现。注意伪造 IP 头只应该在你有权限的系统上测试不要拿去做任何绕过访问控制的非法操作。2. 伪造 IP 头的工作原理从请求头到测试价值2.1 服务端如何判断请求来源 IP从 TCP 层到 HTTP 头服务端判断客户端 IP 有两个层面。第一层是 TCP 连接的直接来源也就是 socket 对端的 IP第二层是 HTTP 协议里携带的转发头最常见的是 X-Forwarded-ForXFF、X-Real-IP、X-Client-IP、True-Client-IP 等。当请求经过反向代理、CDN、负载均衡时这些代理会在转发请求时把自己的出口 IP 或真实客户端 IP 写在特定的请求头里后端应用如果需要拿到原始客户端 IP就从这些头里去取。关键点在于HTTP 头是客户端能直接控制的如果代理没有覆盖而是追加那么原始请求里伪造的头可能会被后端读到。这就给测试提供了一个切入点——通过修改请求头你能模拟请求来自任意 IP而不需要真的去拥有那个 IP。多级代理链路里这种透传问题更明显。比如客户端 → CDN → Nginx → 应用如果 CDN 把自己的出口 IP 追加到 XFF 后面但 Nginx 又用 proxy_set_header 强制覆写那么最终应用读到的可能是中间某层的 IP。有些系统配置不规范直接在应用层信任 XFF 的第一个值这就让请求头里的伪造空间变得很大。你会发现同样一个接口直接 curl 和带 XFF 访问业务行为完全不一样这正是 Fake IP 类扩展能派上用场的测试场景。从测试价值来说Fake IP 头能触达这几类问题第一访问控制缺陷比如只校验 IP 是否在某个网段而网段可以通过头伪造第二会话固定与 IP 绑定逻辑比如登录后 IP 变化导致会话失效或者 IP 变化不失效这两类异常都值得记录第三风控策略强度验证随机 IP 能否绕过频率限制如果绕过了就说明风控有问题。搞清楚服务端信任哪一个层级的 IP是使用这类扩展前必须做的功课否则就是盲猜。2.2 Burp 扩展如何接管请求从监听器到 Header 修改Burp 扩展的基本机制是 IBurpExtender 接口所有 Java 写的扩展都需要实现这个接口然后在 registerExtenderCallbacks 里注册各种监听器。修改请求头用的是 IHttpListener 的 processHttpRequest 方法这个方法会在请求被发送到服务器之前被调用你可以在这里拿到 requestInfo调用 getHeaders() 获取头部列表再修改后通过 callbacks.applyRequestChanges 写回去。这是最标准的扩展回调路线Repeater、Intruder、Scanner 发出的请求都会走这个入口。下面是这类扩展最常见的骨架代码Javaimport burp.IBurpExtender; import burp.IBurpExtenderCallbacks; import burp.IHttpListener; import burp.IHttpRequestResponse; import burp.IRequestInfo; public class FakeIPExtender implements IBurpExtender, IHttpListener { private IBurpExtenderCallbacks callbacks; Override public void registerExtenderCallbacks(IBurpExtenderCallbacks callbacks) { this.callbacks callbacks; callbacks.setExtensionName(Fake IP Helper); callbacks.registerHttpListener(this); } Override public void processHttpRequest(int toolFlag, boolean messageIsRequest, IHttpRequestResponse messageInfo) { // 只处理请求方向不处理响应 if (!messageIsRequest) return; IRequestInfo requestInfo callbacks.helpers.analyzeRequest(messageInfo); java.util.ListString headers requestInfo.getHeaders(); // 这里插入你需要的头处理逻辑下一章会具体说 // 比如给 headers 增加或替换 X-Forwarded-For headers modifyHeaders(headers); messageInfo.setRequest(callbacks.helpers.buildHttpMessage(headers, messageInfo.getRequest(), requestInfo.getBodyOffset())); } private java.util.ListString modifyHeaders(java.util.ListString headers) { // 实际逻辑遍历 headers删除已有的 X-Forwarded-For 等再添加随机值 return headers; } }逻辑说明registerExtenderCallbacks 里注册了 HttpListener这样所有 HTTP 请求都会经过 processHttpRequest。getHeaders() 返回的列表里包括请求行的第一项比如 GET /path HTTP/1.1后续是 Host、Cookie 等。buildHttpMessage 接收新的头列表和原始请求体bodyOffset 用于找出请求体起始位置保证头修改不影响请求体。这里故意用了 java.util.List 的完整限定名避免导入冲突实际工程里可以加 import。参数说明toolFlag 表示当前请求来自哪个 Burp 工具如果只想影响 Intruder可以用 int 值比较messageIsRequest 用来区分请求和响应必须在处理请求时才改头IRequestInfo.getBodyOffset 返回 body 的字节偏移用于把头和 body 拆开。常见误用是没有判断 messageIsRequest 就改头导致响应也被尝试修改虽然响应没有请求头但会浪费性能。这里有个关键设计选择是替换已有头还是追加新头。如果服务端只认第一个 XFF追加可能不生效如果服务端读的是最后一个追加可能有效。最稳妥的做法是删除所有同名头再插入一个新的确保你构造的值是唯一的。另一个细节是头名的大小写HTTP 协议规定头名不区分大小写但有些旧应用用 Map 存储头时没做归一化导致 X-Forwarded-For 和 x-forwarded-for 被当成两个字段。扩展里最好统一把头名转成标准驼峰形式避免这种玄学问题。3. 把 burpFakeIP-master.zip 跑起来加载与最小配置拿到压缩包后第一件事是確認它是不是一个源码工程。常见结构是 src/main/java 加 build.gradle 或 pom.xml也可能已经带了编译好的 jar。如果你看到的是源码那么需要先构建如果直接有 jar可以跳过编译步骤。下面我按最常见的源码工程来写。3.1 解压与编译确认工程类型和构建命令解压后通常会看到这样的文件布局burpFakeIP-master/ ├── pom.xml # Maven 构建文件 ├── build.gradle # 或者 Gradle 构建文件 ├── src/ │ └── main/ │ └── java/ │ └── burp/ # Burp 扩展源码 └── README.md # 说明文档如果你没有源码包只拿到一个 jar可以直接跳到 3.2 加载。如果是 Maven 工程我一般用这个命令编译cd burpFakeIP-master mvn clean package -DskipTests如果看到的是 Gradle 工程对应命令是cd burpFakeIP-master gradle clean build shadowJar构建完成后在 target 或者 build/libs 目录下会生成一个带依赖的 jar 文件。注意Burp 扩展需要用 Burp 提供的 API 编译但运行时 Burp 自己会提供 burp 包所以打出来的 jar 不需要包含 Burp API 的源代码只需要包含你自己写的类和第三方依赖。要求使用 shadow 或 shade 插件是为了把第三方依赖打进去否则加载时容易报 ClassNotFoundException。参数说明mvn clean package 会先清理再打包-DskipTests 跳过测试减少不必要的耗时shadowJar 生成的是 fat jar能把所有依赖都塞进去这是 Burp 扩展常见做法。如果构建报错优先检查 JDK 版本Burp 扩展一般建议用 JDK 8 或 11。构建过程中如果遇到依赖下载超时可以去 Maven 中央仓库确认网络连通性常见原因是公司内部仓库源没生效。3.2 在 Burp 中加载扩展并打开开关构建完成后打开 Burp Suite进入 Extensions 标签页点击 Add选择 Java然后选择刚才生成的 jar。加载成功后列表里会出现扩展名如果看到 Output 里有错误说明源码或依赖有问题。加载后一般会在 Burp 顶部菜单或者右键菜单里多出一个配置窗口取决于扩展作者怎么写的也有的是通过配置文件控制。常见做法是扩展只提供一个默认行为把所有经过代理的请求的 X-Forwarded-For 和 X-Real-IP 替换为随机值。如果没有图形界面扩展通常会读取当前工作目录下的 fakeip.conf 或类似文件。配置项一般包括enabledtrue headernamesX-Forwarded-For,X-Real-IP,X-Client-IP mappingrandom random.subnet192.0.2.0/24 exclude.hostsexample.com,internal.local逻辑说明enabled 是整个扩展的总开关false 时直接不修改请求。headernames 指定要操作哪些头你可以只让扩展改 XFF保留其他头。mapping 决定是随机生成还是固定一个值。random.subnet 让随机 IP 限制在某个网段内。exclude.hosts 设置排除列表避免对无关站点生效。配置文件的读取代码在扩展加载时会自动执行如果你改了配置需要重启扩展或重新加载 jar。有些实现为了方便测试还支持一个 fixed.ip 字段你可以直接填 192.0.2.55扩展就每次都用这个值。参数说明随机 IP 不要用公网段建议用 RFC 5737 定义的文档网络 192.0.2.0/24、198.51.100.0/24、203.0.113.0/24这样不会误伤真实网络。排除列表支持域名精确匹配有的实现还支持通配符 *.example.com。如果你发现自己访问目标时不生效先看看排除列表是否把目标误加了进去。另外如果扩展提供界面界面里的参数会和配置文件互相同步改完界面记得点 Save 或者 Apply否则重启后还是旧配置。3.3 用一条请求验证扩展是否生效加载好之后最快验证方法是找一个回显 IP 的接口。常见做法是启动一个本地 Flask 服务代码在最后一章给出如果没有本地环境也可以用一个能在响应体里返回请求头信息的测试接口。但更稳的是自己动手搭。先用 Burp Proxy 打开拦截发任意请求在 Raw 标签里能看到请求头已经被修改。如果没有拦截可以直接用 Repeater 发包然后看响应对应的业务行为比如同一个接口连续发几次服务端记录到不同来源 IP说明扩展生效。验证时我习惯同时开两个 Burp 工具窗口一个开 Repeater 看头一个开 Logger 看实际发出的完整请求。Logger 里能看到的是最终经过所有扩展处理后的请求比 Repeater 面板更接近真实。注意有些扩展会同时修改请求行比如改变 Host或者合并重复头这类副作用需要通过 Logger 抓出来。如果发现扩展把请求改坏了先关掉开关再做减法定位是哪一个头导致的。这一步能排除大部分「以为生效其实没有」的翻车现场。4. 调参实战随机策略、排除规则与会话绑定4.1 随机 IP 生成策略完全随机、子网随机、固定网段扩展的核心是 IP 生成。最简单的是完全随机即每次生成一个 32 位整数然后转成点分十进制。但这里有没有坑如果你生成的 IP 是保留网段或者广播地址某些服务端可能直接拒绝。所以我一般用子网限制让生成的 IP 在某个可路由网段内。下面是一段常用的随机 IP 生成代码import java.util.Random; public class FakeIpGenerator { private static final Random RANDOM new Random(); private final int base; private final int mask; private final int count; public FakeIpGenerator(String cidr) { String[] parts cidr.split(/); int ip ipToInt(parts[0]); int prefix Integer.parseInt(parts[1]); // 计算网络号、掩码和可用地址数 this.mask prefix 0 ? 0 : (0xFFFFFFFF (32 - prefix)); this.base ip mask; this.count (1 (32 - prefix)) - 2; // 去掉网络地址和广播地址 } public String nextIp() { // 可用地址范围内随机取一个偏移 int offset RANDOM.nextInt(count) 1; int value base offset; return intToIp(value); } private static int ipToInt(String ip) { String[] octets ip.split(\\.); return (Integer.parseInt(octets[0]) 24) | (Integer.parseInt(octets[1]) 16) | (Integer.parseInt(octets[2]) 8) | Integer.parseInt(octets[3]); } private static String intToIp(int value) { return String.format(%d.%d.%d.%d, (value 24) 0xFF, (value 16) 0xFF, (value 8) 0xFF, value 0xFF); } }逻辑说明构造方法把 CIDR 字符串解析成网络号和掩码。ipToInt 把 IP 转成 int再与掩码相与得到网络地址。nextIp 在可用地址范围内随机取一个偏移最后拼成 IP。count 计算时减 2 是为了跳过网络地址和广播地址如果你用的网段是 192.0.2.0/24那么可用地址是 192.0.2.1 到 192.0.2.254。如果你需要固定 IP直接不调用 nextIp而是用构造参数里给定的固定值。参数说明prefix 越大可用地址越少/24 有 254 个/16 有 65534 个。这里有一个容易踩的坑如果你写的是 192.0.2.1/24构造方法会先把它按 /24 的掩码归一化基地址变成 192.0.2.0这是正确的。但如果你不小心传了 10.0.0.1/8那所有虚拟 IP 都在 10.0.0.0/8 内服务端看到一堆 10 网段地址可能触达内网策略。所以随机子网一定要和业务网络区分开。这里有个设计选择是每个请求都换 IP还是每个连接固定 IP。做并发 fuzz 时如果每个请求都换 IP服务端看到的是一堆杂乱来源不利于分析。常见做法是绑定线程槽thread slotBurp Intruder 的每个攻击线程在初始化时生成一个 IP之后该线程所有请求都用这个 IP。下一节会讲怎么实现绑定。4.2 排除列表与 URL 范围只对目标请求生效如果不加限制扩展会给所有经过 Burp 的请求都加上伪造 IP这会导致访问外网测试接口时数据全部被污染。所以成熟的实现一定要有 scope 控制。Burp 自身有 Scope 设置扩展可以读取 callbacks.isInScope(url) 判断请求 URL 是否在范围内。当然也有扩展自己维护一份排除列表。我一般推荐双保险先按 Burp 的 scope再叠加扩展自身的 exclude.hosts 配置。判断范围的常见代码if (!callbacks.isInScope(callbacks.helpers.analyzeRequest(messageInfo).getUrl())) { return; // 不在范围内直接跳过 }逻辑说明isInScope 会读取你在 Burp Target 页面设置的 Suite Scope如果你没设置这个调用默认返回 trueBurp 里默认所有 URL 都在 scope 内所以要在加载扩展前先把 Target Scope 配置好。另一个硬道理是测试目标域名必须精确加进 Scope不要用 IP 段否则容易误伤云上其他服务。参数说明exclude.hosts 建议按域名写不要带协议和路径。如果在排除列表里写了 example.com那么 www.example.com 不会匹配需要再写一条。有的实现支持通配符可以写 *.example.com但要注意这同时也匹配了 a.b.example.com层级越多越容易出错。测试经验是先让扩展只对一个测试域名生效确认稳定后再扩大到目标范围。除了 host 级排除还需要考虑 URL 路径级排除。比如 /api/v1/health 这样的健康检查接口如果改了头可能触发报警。实现时可以在配置里加一个 exclude.paths 字段用逗号分隔前缀代码里判断 uri 是否以某个前缀开头。4.3 会话绑定与并发让 fuzz 时每个线程用不同 IP做登录测试或撞库测试时如果每个请求来源 IP 都在变服务端风控可能直接锁定当前会话。更合理的做法是把 IP 与会话绑定。比如你有一个登录接口想模拟一个来源 IP 连续试探多个账号那么这些请求应该用同一个 IP不同 IP 之间是不同用户。实际实现可以通过线程槽来绑定。下面是一个简单的映射import java.util.concurrent.ConcurrentHashMap; public class IpSession { private static final ConcurrentHashMapInteger, String threadIp new ConcurrentHashMap(); private static final FakeIpGenerator generator new FakeIpGenerator(192.0.2.0/24); public static String getIpForThread(int threadNumber) { // 每个线程首次调用时生成并缓存 IP之后一直复用 return threadIp.computeIfAbsent(threadNumber, k - generator.nextIp()); } }逻辑说明ConcurrentHashMap 的 computeIfAbsent 保证同一线程只会生成一次 IP不同线程会拿到不同 IP。使用这个类时在 processHttpRequest 里通过某个上下文获取当前线程号。Burp 扩展 API 没有直接暴露线程号但可以自己维护一个 AtomicInteger 取模把请求分配给固定数量的槽。更常见的是配合 Intruder在攻击开始时给每个 payload 槽分配一个 IP然后通过 messageInfo 的递增计数器来复用。参数说明如果同时使用多个 Burp 工具Repeater 每次点击生成一个请求无法用线程槽区分这时可以按「目标 host 会话 Cookie」来绑定 IP。换句话说会话绑定不止线程绑定一种还可以把 IP 作为 session 的关联字段。关键在于确定你需要的是「同一来源多次请求」还是「多个来源并行请求」然后选择对应的粒度。如果不绑定Fake IP 工具就退化成随机头生成器这是很多人在 Intruder 里翻车的根本原因。参数速查表如下参数可选值说明推荐设置mappingrandom/fixed随机 IP 还是固定 IP调试用 fixed风控测试用 randomrandom.subnetCIDR随机 IP 所在子网192.0.2.0/24fixed.ipIP 地址固定 IP 的值192.0.2.66headernames逗号分隔需要改写的头名列表X-Forwarded-For,X-Real-IPexclude.hosts逗号分隔命中域名不改写内部域名exclude.paths逗号分隔命中路径前缀不改写/health,/metricssession.modeoff/thread/cookie绑定粒度fuzz 用 thread表格里的 session.mode 不是每个实现都有但属于成熟工具应该提供的维度。如果你拿到的扩展没有可以考虑自己改源码加上这一块改动不大。5. 常见问题与排查扩展不生效、随机失效、影响业务5.1 现象请求头已经改掉了但服务端看到的 IP 没变现象在 Burp 里看请求头X-Forwarded-For 确实被替换了但业务接口返回的来源 IP 还是原来的。原因有几种第一种服务端根本不读 XFF而是从 TCP socket 取对端 IP第二种服务端前面还有一层代理代理会覆盖你设置的头第三种服务端读取的是另一个头名字比如 X-Real-IP你没改到。解决方法确认服务端日志里记录的是哪个头的值通常可以看网关配置或者应用框架的头解析代码。然后扩展里把可能生效的头全部改一遍包括 XFF、X-Real-IP、X-Client-IP、True-Client-IP。如果服务端直连客户端没有代理那么 TCP 层 IP 没法靠改头欺骗你需要换一个合法的网络出口而不是用 Fake IP。注意扩展只能影响 HTTP 头改动不了 TCP 层。有些测试者误以为设置一个伪造头就能让服务端 log 看到假 IP这在没有代理中转的网络里是做不到的。想验证这一点可以本地搭个回显接口对比 remote 和 xff 的值具体做法看下一章。5.2 现象扩展加载后整个 Burp 变卡请求响应明显延迟现象打开扩展开关后每个请求都变慢Intruder 跑起来很费力。原因扩展在 processHttpRequest 里做了重活比如正则匹配大文本或者在生成 IP 时每次 new 一个 Random。Random 是线程安全的但频繁调用会有锁竞争再加上没有对请求做范围过滤每个静态资源请求都处理一遍性能自然下降。解决把 Random 改成 ThreadLocalRandom在扩展加载时初始化一次不要每次生成都 new。另外在 processHttpRequest 最前面加范围判断过滤掉图片、CSS、JS 等静态资源。如果扩展支持排除列表就把无关域名全部加进去。性能排查方法先在 Burp 的 Extensions 面板把扩展 Disable然后跑同样一个 Intruder 任务对比完成时间再 Enable 跑一次。如果差距超过 30%说明扩展处理链路有问题。之后在代码里加 System.currentTimeMillis 统计每个请求的处理耗时打印到 Output 面板定位是哪个方法慢。5.3 现象HTTPS 请求被改头后业务签名校验失败现象某些接口做了参数签名比如把请求头里的某些字段参与签名你改了 IP 头导致签名不匹配接口直接报错。原因这不是扩展的 bug而是业务系统对头部有完整性校验。解决使用扩展的「按 host 排除」功能让特定接口不经过 Fake IP或者只修改服务端用来取 IP 的那一个头不要全改。如果业务校验的是所有可见头那伪造 IP 在这个系统上就不可行你需要先在测试环境关掉校验再测业务逻辑。这里有一个实际测试技巧先看设备环境里的接口文档确认哪些头参与签名然后只对不参与签名的头做 Fake IP。比如很多系统只对 body 做签名头的改动不影响验签那就可以放心用。如果所有头都参与签名建议不要在这个目标上做 IP 维度测试而是去测别的维度。5.4 现象加载 jar 时报 ClassNotFoundException 或 NoClassDefFoundError现象Burp 的 Extensions 面板显示加载失败Output 里有 ClassNotFoundException: org.apache.commons.lang3.StringUtils 之类的报错。原因扩展依赖了第三方库但打包时没有把依赖包含进去Burp 的类加载器找不到。解决用 Maven 的 shade 插件或 Gradle 的 shadow 插件重新打包确保生成 fat jar。如果你拿到的是别人编译好的 jar不要自己去改源码先确认它的构建配置。另外 JDK 版本不匹配也会出现类似问题Burp 自带的运行时如果版本过老扩展用了更高版本 API建议按扩展 README 要求的环境配置。如果报了 NoClassDefFoundError 而不是 ClassNotFoundException情况更隐蔽。它表示类在编译期存在但运行期某个类初始化失败。这种情况一般出现在静态初始化块里比如 Random 或第三方库读取外部配置。可以先在本地用java -jar跑一下看堆栈信息确认是不是路径依赖问题。Burp 里加载失败时Output 面板会打印完整堆栈第一屏只是摘要往下拉就能看到原因。5.5 现象伪造 IP 后登录态失效或登录成功后又掉线现象使用固定 IP 时登录正常使用随机 IP 时每次请求都登录失败或被登出。原因服务端把 Session 或 Token 绑定到了来源 IPIP 一变就视为新会话。做越权测试时这正是你要验证的点但如果只是普通调试这就成了阻碍。解决在扩展配置里把 mapping 改为 fixed 并填一个固定的 IP或者按会话绑定让同一个 Cookie 的请求始终使用同一个 IP。扩展如果支持「从已有请求中读取来源 IP」你可以在首次请求后锁定后续请求复用。这类问题的另一面是不同 IP 来源触发了风控比如短时间内大量不同 IP 登录同一个账号服务端直接限制了该账号。这时候需要降低并发或者在两次请求之间加延时。不要每发一个请求就换一个新 IP那样很容易被识别为攻击流量导致测试中断。6. 进阶验证用回显服务器确认伪造结果结合 Intruder 做越权测试6.1 搭建一个回显 IP 的本地接口为了确认扩展是否真的改变了服务端视角的 IP最好在本地起一个回显接口。这里用 Flask 写一个最小服务from flask import Flask, request app Flask(__name__) app.route(/ip) def ip(): # 按常见优先级回显来源 IP xff request.headers.get(X-Forwarded-For, ) real request.headers.get(X-Real-IP, ) remote request.remote_addr return fxff{xff} real{real} remote{remote} app.run(host0.0.0.0, port8888)逻辑说明/ip 接口会分别返回 XFF 头、X-Real-IP 头和 TCP 层的 remote_addr。你在 Burp 里把请求代理到扩展再发给这个接口对比三项就能直观看到扩展改的是哪些。参数说明remote 是 TCP 层实际来源只要 Burp 代理本机它一直是 127.0.0.1xff 和 real 的值取决于扩展配置。如果扩展生效而你设置的 IP 有效xff 或 real 就会出现你伪造的值。启动服务时可以加--reload参数方便调试但注意实际测试时不要开 reload否则日志会被打断。你也可以用 Spring Boot 写一个等价接口逻辑完全一样选 Flask 只是因为快。6.2 与 Intruder 配合做来源维度测试最后一个实用技巧在 Intruder 里跑越权或撞库测试时把扩展的固定 IP 模式和 payload 位置错开。比如 payload 是用户名每个线程固定一个 IP这样模拟多个 IP 分别尝试不同账号能更真实地复现分布式来源的攻击场景。具体做法是先让扩展按线程槽生成 IP然后观察服务端日志确认每个线程的来源 IP 是否独立。我自己的习惯是先用回显接口跑一个 10 线程的冒烟测试确认 IP 分布符合预期再正式跑业务。如果你拿到的扩展没有线程绑定功能可以用一个取巧方案把 payload 的一部分作为 IP 的输入。比如 payload 是 user001扩展会从 payload 里截取最后三位转成 IP 的第四段这样就实现了「每个 payload 固定一个 IP」。这种改法需要扩展提供模板变量支持没有的话就得自己改源码了。这几步做完你对这个扩展的掌控就从「黑匣子」变成了「可解释的工具」。血泪经验是Fake IP 不是点一下开关就完事的它需要配合业务对 IP 的信任模型来做调整。先把回显接口搭起来再调参最后上并发这套顺序能少踩很多坑。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/15 17:54:26 · 阅读 1.2k Burp扩展伪造IP头：玩转X-Forwarded-For与接口安全测试
简介burpFakeIP-master.zip 是一款面向 Web 安全测试人员的 Burp Suite 插件资源包用于在渗透测试或授权评估中模拟不同源 IP 地址规避基于 IP 的访问限制同时保护测试者身份。该插件基于 Python 编写核心代码为 fakeIP.py配合 README.md 说明文档可快速了解配置方式包内 12 个文件以 9 张 png 截图为主直观展示插件界面与配置步骤另有 test.txt 用于测试验证。压缩包整体仅 1.09MB轻量易部署适合 Burp Suite 的初中级使用者扩展工具链。已有 412 人学习下载资源来自 GitHub 开源项目包含完整插件源码、使用说明和效果截图读者可据此理解 IP 伪装实现思路并直接导入扩展使用提升测试隐蔽性与多场景模拟能力。1. burpFakeIP 是什么一个让测试请求“换头”的 Burp 扩展从 burpFakeIP-master.zip 这个包名就能猜到这是一个针对 Burp Suite 的扩展核心能力是给发出去的请求批量伪造或随机化 IP 头。做接口测试、越权测试、风控调试的人经常会遇到一个问题服务端根据来源 IP 做限制而测试机 IP 只有一个很多场景复现不出来。比如登录接口有同 IP 限流或者某个接口只有特定网段才能访问手动在 Proxy 里改 X-Forwarded-For 又慢又容易漏。这个扩展就是把这些操作自动化让你在 Burp 里像开关一样控制请求头里的 IP 信息。适合授权范围内的安全测试、开发阶段联调、线上问题复现。注意伪造 IP 头只应该在你有权限的系统上测试不要拿去做任何绕过访问控制的非法操作。2. 伪造 IP 头的工作原理从请求头到测试价值2.1 服务端如何判断请求来源 IP从 TCP 层到 HTTP 头服务端判断客户端 IP 有两个层面。第一层是 TCP 连接的直接来源也就是 socket 对端的 IP第二层是 HTTP 协议里携带的转发头最常见的是 X-Forwarded-ForXFF、X-Real-IP、X-Client-IP、True-Client-IP 等。当请求经过反向代理、CDN、负载均衡时这些代理会在转发请求时把自己的出口 IP 或真实客户端 IP 写在特定的请求头里后端应用如果需要拿到原始客户端 IP就从这些头里去取。关键点在于HTTP 头是客户端能直接控制的如果代理没有覆盖而是追加那么原始请求里伪造的头可能会被后端读到。这就给测试提供了一个切入点——通过修改请求头你能模拟请求来自任意 IP而不需要真的去拥有那个 IP。多级代理链路里这种透传问题更明显。比如客户端 → CDN → Nginx → 应用如果 CDN 把自己的出口 IP 追加到 XFF 后面但 Nginx 又用 proxy_set_header 强制覆写那么最终应用读到的可能是中间某层的 IP。有些系统配置不规范直接在应用层信任 XFF 的第一个值这就让请求头里的伪造空间变得很大。你会发现同样一个接口直接 curl 和带 XFF 访问业务行为完全不一样这正是 Fake IP 类扩展能派上用场的测试场景。从测试价值来说Fake IP 头能触达这几类问题第一访问控制缺陷比如只校验 IP 是否在某个网段而网段可以通过头伪造第二会话固定与 IP 绑定逻辑比如登录后 IP 变化导致会话失效或者 IP 变化不失效这两类异常都值得记录第三风控策略强度验证随机 IP 能否绕过频率限制如果绕过了就说明风控有问题。搞清楚服务端信任哪一个层级的 IP是使用这类扩展前必须做的功课否则就是盲猜。2.2 Burp 扩展如何接管请求从监听器到 Header 修改Burp 扩展的基本机制是 IBurpExtender 接口所有 Java 写的扩展都需要实现这个接口然后在 registerExtenderCallbacks 里注册各种监听器。修改请求头用的是 IHttpListener 的 processHttpRequest 方法这个方法会在请求被发送到服务器之前被调用你可以在这里拿到 requestInfo调用 getHeaders() 获取头部列表再修改后通过 callbacks.applyRequestChanges 写回去。这是最标准的扩展回调路线Repeater、Intruder、Scanner 发出的请求都会走这个入口。下面是这类扩展最常见的骨架代码Javaimport burp.IBurpExtender; import burp.IBurpExtenderCallbacks; import burp.IHttpListener; import burp.IHttpRequestResponse; import burp.IRequestInfo; public class FakeIPExtender implements IBurpExtender, IHttpListener { private IBurpExtenderCallbacks callbacks; Override public void registerExtenderCallbacks(IBurpExtenderCallbacks callbacks) { this.callbacks callbacks; callbacks.setExtensionName(Fake IP Helper); callbacks.registerHttpListener(this); } Override public void processHttpRequest(int toolFlag, boolean messageIsRequest, IHttpRequestResponse messageInfo) { // 只处理请求方向不处理响应 if (!messageIsRequest) return; IRequestInfo requestInfo callbacks.helpers.analyzeRequest(messageInfo); java.util.ListString headers requestInfo.getHeaders(); // 这里插入你需要的头处理逻辑下一章会具体说 // 比如给 headers 增加或替换 X-Forwarded-For headers modifyHeaders(headers); messageInfo.setRequest(callbacks.helpers.buildHttpMessage(headers, messageInfo.getRequest(), requestInfo.getBodyOffset())); } private java.util.ListString modifyHeaders(java.util.ListString headers) { // 实际逻辑遍历 headers删除已有的 X-Forwarded-For 等再添加随机值 return headers; } }逻辑说明registerExtenderCallbacks 里注册了 HttpListener这样所有 HTTP 请求都会经过 processHttpRequest。getHeaders() 返回的列表里包括请求行的第一项比如 GET /path HTTP/1.1后续是 Host、Cookie 等。buildHttpMessage 接收新的头列表和原始请求体bodyOffset 用于找出请求体起始位置保证头修改不影响请求体。这里故意用了 java.util.List 的完整限定名避免导入冲突实际工程里可以加 import。参数说明toolFlag 表示当前请求来自哪个 Burp 工具如果只想影响 Intruder可以用 int 值比较messageIsRequest 用来区分请求和响应必须在处理请求时才改头IRequestInfo.getBodyOffset 返回 body 的字节偏移用于把头和 body 拆开。常见误用是没有判断 messageIsRequest 就改头导致响应也被尝试修改虽然响应没有请求头但会浪费性能。这里有个关键设计选择是替换已有头还是追加新头。如果服务端只认第一个 XFF追加可能不生效如果服务端读的是最后一个追加可能有效。最稳妥的做法是删除所有同名头再插入一个新的确保你构造的值是唯一的。另一个细节是头名的大小写HTTP 协议规定头名不区分大小写但有些旧应用用 Map 存储头时没做归一化导致 X-Forwarded-For 和 x-forwarded-for 被当成两个字段。扩展里最好统一把头名转成标准驼峰形式避免这种玄学问题。3. 把 burpFakeIP-master.zip 跑起来加载与最小配置拿到压缩包后第一件事是確認它是不是一个源码工程。常见结构是 src/main/java 加 build.gradle 或 pom.xml也可能已经带了编译好的 jar。如果你看到的是源码那么需要先构建如果直接有 jar可以跳过编译步骤。下面我按最常见的源码工程来写。3.1 解压与编译确认工程类型和构建命令解压后通常会看到这样的文件布局burpFakeIP-master/ ├── pom.xml # Maven 构建文件 ├── build.gradle # 或者 Gradle 构建文件 ├── src/ │ └── main/ │ └── java/ │ └── burp/ # Burp 扩展源码 └── README.md # 说明文档如果你没有源码包只拿到一个 jar可以直接跳到 3.2 加载。如果是 Maven 工程我一般用这个命令编译cd burpFakeIP-master mvn clean package -DskipTests如果看到的是 Gradle 工程对应命令是cd burpFakeIP-master gradle clean build shadowJar构建完成后在 target 或者 build/libs 目录下会生成一个带依赖的 jar 文件。注意Burp 扩展需要用 Burp 提供的 API 编译但运行时 Burp 自己会提供 burp 包所以打出来的 jar 不需要包含 Burp API 的源代码只需要包含你自己写的类和第三方依赖。要求使用 shadow 或 shade 插件是为了把第三方依赖打进去否则加载时容易报 ClassNotFoundException。参数说明mvn clean package 会先清理再打包-DskipTests 跳过测试减少不必要的耗时shadowJar 生成的是 fat jar能把所有依赖都塞进去这是 Burp 扩展常见做法。如果构建报错优先检查 JDK 版本Burp 扩展一般建议用 JDK 8 或 11。构建过程中如果遇到依赖下载超时可以去 Maven 中央仓库确认网络连通性常见原因是公司内部仓库源没生效。3.2 在 Burp 中加载扩展并打开开关构建完成后打开 Burp Suite进入 Extensions 标签页点击 Add选择 Java然后选择刚才生成的 jar。加载成功后列表里会出现扩展名如果看到 Output 里有错误说明源码或依赖有问题。加载后一般会在 Burp 顶部菜单或者右键菜单里多出一个配置窗口取决于扩展作者怎么写的也有的是通过配置文件控制。常见做法是扩展只提供一个默认行为把所有经过代理的请求的 X-Forwarded-For 和 X-Real-IP 替换为随机值。如果没有图形界面扩展通常会读取当前工作目录下的 fakeip.conf 或类似文件。配置项一般包括enabledtrue headernamesX-Forwarded-For,X-Real-IP,X-Client-IP mappingrandom random.subnet192.0.2.0/24 exclude.hostsexample.com,internal.local逻辑说明enabled 是整个扩展的总开关false 时直接不修改请求。headernames 指定要操作哪些头你可以只让扩展改 XFF保留其他头。mapping 决定是随机生成还是固定一个值。random.subnet 让随机 IP 限制在某个网段内。exclude.hosts 设置排除列表避免对无关站点生效。配置文件的读取代码在扩展加载时会自动执行如果你改了配置需要重启扩展或重新加载 jar。有些实现为了方便测试还支持一个 fixed.ip 字段你可以直接填 192.0.2.55扩展就每次都用这个值。参数说明随机 IP 不要用公网段建议用 RFC 5737 定义的文档网络 192.0.2.0/24、198.51.100.0/24、203.0.113.0/24这样不会误伤真实网络。排除列表支持域名精确匹配有的实现还支持通配符 *.example.com。如果你发现自己访问目标时不生效先看看排除列表是否把目标误加了进去。另外如果扩展提供界面界面里的参数会和配置文件互相同步改完界面记得点 Save 或者 Apply否则重启后还是旧配置。3.3 用一条请求验证扩展是否生效加载好之后最快验证方法是找一个回显 IP 的接口。常见做法是启动一个本地 Flask 服务代码在最后一章给出如果没有本地环境也可以用一个能在响应体里返回请求头信息的测试接口。但更稳的是自己动手搭。先用 Burp Proxy 打开拦截发任意请求在 Raw 标签里能看到请求头已经被修改。如果没有拦截可以直接用 Repeater 发包然后看响应对应的业务行为比如同一个接口连续发几次服务端记录到不同来源 IP说明扩展生效。验证时我习惯同时开两个 Burp 工具窗口一个开 Repeater 看头一个开 Logger 看实际发出的完整请求。Logger 里能看到的是最终经过所有扩展处理后的请求比 Repeater 面板更接近真实。注意有些扩展会同时修改请求行比如改变 Host或者合并重复头这类副作用需要通过 Logger 抓出来。如果发现扩展把请求改坏了先关掉开关再做减法定位是哪一个头导致的。这一步能排除大部分「以为生效其实没有」的翻车现场。4. 调参实战随机策略、排除规则与会话绑定4.1 随机 IP 生成策略完全随机、子网随机、固定网段扩展的核心是 IP 生成。最简单的是完全随机即每次生成一个 32 位整数然后转成点分十进制。但这里有没有坑如果你生成的 IP 是保留网段或者广播地址某些服务端可能直接拒绝。所以我一般用子网限制让生成的 IP 在某个可路由网段内。下面是一段常用的随机 IP 生成代码import java.util.Random; public class FakeIpGenerator { private static final Random RANDOM new Random(); private final int base; private final int mask; private final int count; public FakeIpGenerator(String cidr) { String[] parts cidr.split(/); int ip ipToInt(parts[0]); int prefix Integer.parseInt(parts[1]); // 计算网络号、掩码和可用地址数 this.mask prefix 0 ? 0 : (0xFFFFFFFF (32 - prefix)); this.base ip mask; this.count (1 (32 - prefix)) - 2; // 去掉网络地址和广播地址 } public String nextIp() { // 可用地址范围内随机取一个偏移 int offset RANDOM.nextInt(count) 1; int value base offset; return intToIp(value); } private static int ipToInt(String ip) { String[] octets ip.split(\\.); return (Integer.parseInt(octets[0]) 24) | (Integer.parseInt(octets[1]) 16) | (Integer.parseInt(octets[2]) 8) | Integer.parseInt(octets[3]); } private static String intToIp(int value) { return String.format(%d.%d.%d.%d, (value 24) 0xFF, (value 16) 0xFF, (value 8) 0xFF, value 0xFF); } }逻辑说明构造方法把 CIDR 字符串解析成网络号和掩码。ipToInt 把 IP 转成 int再与掩码相与得到网络地址。nextIp 在可用地址范围内随机取一个偏移最后拼成 IP。count 计算时减 2 是为了跳过网络地址和广播地址如果你用的网段是 192.0.2.0/24那么可用地址是 192.0.2.1 到 192.0.2.254。如果你需要固定 IP直接不调用 nextIp而是用构造参数里给定的固定值。参数说明prefix 越大可用地址越少/24 有 254 个/16 有 65534 个。这里有一个容易踩的坑如果你写的是 192.0.2.1/24构造方法会先把它按 /24 的掩码归一化基地址变成 192.0.2.0这是正确的。但如果你不小心传了 10.0.0.1/8那所有虚拟 IP 都在 10.0.0.0/8 内服务端看到一堆 10 网段地址可能触达内网策略。所以随机子网一定要和业务网络区分开。这里有个设计选择是每个请求都换 IP还是每个连接固定 IP。做并发 fuzz 时如果每个请求都换 IP服务端看到的是一堆杂乱来源不利于分析。常见做法是绑定线程槽thread slotBurp Intruder 的每个攻击线程在初始化时生成一个 IP之后该线程所有请求都用这个 IP。下一节会讲怎么实现绑定。4.2 排除列表与 URL 范围只对目标请求生效如果不加限制扩展会给所有经过 Burp 的请求都加上伪造 IP这会导致访问外网测试接口时数据全部被污染。所以成熟的实现一定要有 scope 控制。Burp 自身有 Scope 设置扩展可以读取 callbacks.isInScope(url) 判断请求 URL 是否在范围内。当然也有扩展自己维护一份排除列表。我一般推荐双保险先按 Burp 的 scope再叠加扩展自身的 exclude.hosts 配置。判断范围的常见代码if (!callbacks.isInScope(callbacks.helpers.analyzeRequest(messageInfo).getUrl())) { return; // 不在范围内直接跳过 }逻辑说明isInScope 会读取你在 Burp Target 页面设置的 Suite Scope如果你没设置这个调用默认返回 trueBurp 里默认所有 URL 都在 scope 内所以要在加载扩展前先把 Target Scope 配置好。另一个硬道理是测试目标域名必须精确加进 Scope不要用 IP 段否则容易误伤云上其他服务。参数说明exclude.hosts 建议按域名写不要带协议和路径。如果在排除列表里写了 example.com那么 www.example.com 不会匹配需要再写一条。有的实现支持通配符可以写 *.example.com但要注意这同时也匹配了 a.b.example.com层级越多越容易出错。测试经验是先让扩展只对一个测试域名生效确认稳定后再扩大到目标范围。除了 host 级排除还需要考虑 URL 路径级排除。比如 /api/v1/health 这样的健康检查接口如果改了头可能触发报警。实现时可以在配置里加一个 exclude.paths 字段用逗号分隔前缀代码里判断 uri 是否以某个前缀开头。4.3 会话绑定与并发让 fuzz 时每个线程用不同 IP做登录测试或撞库测试时如果每个请求来源 IP 都在变服务端风控可能直接锁定当前会话。更合理的做法是把 IP 与会话绑定。比如你有一个登录接口想模拟一个来源 IP 连续试探多个账号那么这些请求应该用同一个 IP不同 IP 之间是不同用户。实际实现可以通过线程槽来绑定。下面是一个简单的映射import java.util.concurrent.ConcurrentHashMap; public class IpSession { private static final ConcurrentHashMapInteger, String threadIp new ConcurrentHashMap(); private static final FakeIpGenerator generator new FakeIpGenerator(192.0.2.0/24); public static String getIpForThread(int threadNumber) { // 每个线程首次调用时生成并缓存 IP之后一直复用 return threadIp.computeIfAbsent(threadNumber, k - generator.nextIp()); } }逻辑说明ConcurrentHashMap 的 computeIfAbsent 保证同一线程只会生成一次 IP不同线程会拿到不同 IP。使用这个类时在 processHttpRequest 里通过某个上下文获取当前线程号。Burp 扩展 API 没有直接暴露线程号但可以自己维护一个 AtomicInteger 取模把请求分配给固定数量的槽。更常见的是配合 Intruder在攻击开始时给每个 payload 槽分配一个 IP然后通过 messageInfo 的递增计数器来复用。参数说明如果同时使用多个 Burp 工具Repeater 每次点击生成一个请求无法用线程槽区分这时可以按「目标 host 会话 Cookie」来绑定 IP。换句话说会话绑定不止线程绑定一种还可以把 IP 作为 session 的关联字段。关键在于确定你需要的是「同一来源多次请求」还是「多个来源并行请求」然后选择对应的粒度。如果不绑定Fake IP 工具就退化成随机头生成器这是很多人在 Intruder 里翻车的根本原因。参数速查表如下参数可选值说明推荐设置mappingrandom/fixed随机 IP 还是固定 IP调试用 fixed风控测试用 randomrandom.subnetCIDR随机 IP 所在子网192.0.2.0/24fixed.ipIP 地址固定 IP 的值192.0.2.66headernames逗号分隔需要改写的头名列表X-Forwarded-For,X-Real-IPexclude.hosts逗号分隔命中域名不改写内部域名exclude.paths逗号分隔命中路径前缀不改写/health,/metricssession.modeoff/thread/cookie绑定粒度fuzz 用 thread表格里的 session.mode 不是每个实现都有但属于成熟工具应该提供的维度。如果你拿到的扩展没有可以考虑自己改源码加上这一块改动不大。5. 常见问题与排查扩展不生效、随机失效、影响业务5.1 现象请求头已经改掉了但服务端看到的 IP 没变现象在 Burp 里看请求头X-Forwarded-For 确实被替换了但业务接口返回的来源 IP 还是原来的。原因有几种第一种服务端根本不读 XFF而是从 TCP socket 取对端 IP第二种服务端前面还有一层代理代理会覆盖你设置的头第三种服务端读取的是另一个头名字比如 X-Real-IP你没改到。解决方法确认服务端日志里记录的是哪个头的值通常可以看网关配置或者应用框架的头解析代码。然后扩展里把可能生效的头全部改一遍包括 XFF、X-Real-IP、X-Client-IP、True-Client-IP。如果服务端直连客户端没有代理那么 TCP 层 IP 没法靠改头欺骗你需要换一个合法的网络出口而不是用 Fake IP。注意扩展只能影响 HTTP 头改动不了 TCP 层。有些测试者误以为设置一个伪造头就能让服务端 log 看到假 IP这在没有代理中转的网络里是做不到的。想验证这一点可以本地搭个回显接口对比 remote 和 xff 的值具体做法看下一章。5.2 现象扩展加载后整个 Burp 变卡请求响应明显延迟现象打开扩展开关后每个请求都变慢Intruder 跑起来很费力。原因扩展在 processHttpRequest 里做了重活比如正则匹配大文本或者在生成 IP 时每次 new 一个 Random。Random 是线程安全的但频繁调用会有锁竞争再加上没有对请求做范围过滤每个静态资源请求都处理一遍性能自然下降。解决把 Random 改成 ThreadLocalRandom在扩展加载时初始化一次不要每次生成都 new。另外在 processHttpRequest 最前面加范围判断过滤掉图片、CSS、JS 等静态资源。如果扩展支持排除列表就把无关域名全部加进去。性能排查方法先在 Burp 的 Extensions 面板把扩展 Disable然后跑同样一个 Intruder 任务对比完成时间再 Enable 跑一次。如果差距超过 30%说明扩展处理链路有问题。之后在代码里加 System.currentTimeMillis 统计每个请求的处理耗时打印到 Output 面板定位是哪个方法慢。5.3 现象HTTPS 请求被改头后业务签名校验失败现象某些接口做了参数签名比如把请求头里的某些字段参与签名你改了 IP 头导致签名不匹配接口直接报错。原因这不是扩展的 bug而是业务系统对头部有完整性校验。解决使用扩展的「按 host 排除」功能让特定接口不经过 Fake IP或者只修改服务端用来取 IP 的那一个头不要全改。如果业务校验的是所有可见头那伪造 IP 在这个系统上就不可行你需要先在测试环境关掉校验再测业务逻辑。这里有一个实际测试技巧先看设备环境里的接口文档确认哪些头参与签名然后只对不参与签名的头做 Fake IP。比如很多系统只对 body 做签名头的改动不影响验签那就可以放心用。如果所有头都参与签名建议不要在这个目标上做 IP 维度测试而是去测别的维度。5.4 现象加载 jar 时报 ClassNotFoundException 或 NoClassDefFoundError现象Burp 的 Extensions 面板显示加载失败Output 里有 ClassNotFoundException: org.apache.commons.lang3.StringUtils 之类的报错。原因扩展依赖了第三方库但打包时没有把依赖包含进去Burp 的类加载器找不到。解决用 Maven 的 shade 插件或 Gradle 的 shadow 插件重新打包确保生成 fat jar。如果你拿到的是别人编译好的 jar不要自己去改源码先确认它的构建配置。另外 JDK 版本不匹配也会出现类似问题Burp 自带的运行时如果版本过老扩展用了更高版本 API建议按扩展 README 要求的环境配置。如果报了 NoClassDefFoundError 而不是 ClassNotFoundException情况更隐蔽。它表示类在编译期存在但运行期某个类初始化失败。这种情况一般出现在静态初始化块里比如 Random 或第三方库读取外部配置。可以先在本地用java -jar跑一下看堆栈信息确认是不是路径依赖问题。Burp 里加载失败时Output 面板会打印完整堆栈第一屏只是摘要往下拉就能看到原因。5.5 现象伪造 IP 后登录态失效或登录成功后又掉线现象使用固定 IP 时登录正常使用随机 IP 时每次请求都登录失败或被登出。原因服务端把 Session 或 Token 绑定到了来源 IPIP 一变就视为新会话。做越权测试时这正是你要验证的点但如果只是普通调试这就成了阻碍。解决在扩展配置里把 mapping 改为 fixed 并填一个固定的 IP或者按会话绑定让同一个 Cookie 的请求始终使用同一个 IP。扩展如果支持「从已有请求中读取来源 IP」你可以在首次请求后锁定后续请求复用。这类问题的另一面是不同 IP 来源触发了风控比如短时间内大量不同 IP 登录同一个账号服务端直接限制了该账号。这时候需要降低并发或者在两次请求之间加延时。不要每发一个请求就换一个新 IP那样很容易被识别为攻击流量导致测试中断。6. 进阶验证用回显服务器确认伪造结果结合 Intruder 做越权测试6.1 搭建一个回显 IP 的本地接口为了确认扩展是否真的改变了服务端视角的 IP最好在本地起一个回显接口。这里用 Flask 写一个最小服务from flask import Flask, request app Flask(__name__) app.route(/ip) def ip(): # 按常见优先级回显来源 IP xff request.headers.get(X-Forwarded-For, ) real request.headers.get(X-Real-IP, ) remote request.remote_addr return fxff{xff} real{real} remote{remote} app.run(host0.0.0.0, port8888)逻辑说明/ip 接口会分别返回 XFF 头、X-Real-IP 头和 TCP 层的 remote_addr。你在 Burp 里把请求代理到扩展再发给这个接口对比三项就能直观看到扩展改的是哪些。参数说明remote 是 TCP 层实际来源只要 Burp 代理本机它一直是 127.0.0.1xff 和 real 的值取决于扩展配置。如果扩展生效而你设置的 IP 有效xff 或 real 就会出现你伪造的值。启动服务时可以加--reload参数方便调试但注意实际测试时不要开 reload否则日志会被打断。你也可以用 Spring Boot 写一个等价接口逻辑完全一样选 Flask 只是因为快。6.2 与 Intruder 配合做来源维度测试最后一个实用技巧在 Intruder 里跑越权或撞库测试时把扩展的固定 IP 模式和 payload 位置错开。比如 payload 是用户名每个线程固定一个 IP这样模拟多个 IP 分别尝试不同账号能更真实地复现分布式来源的攻击场景。具体做法是先让扩展按线程槽生成 IP然后观察服务端日志确认每个线程的来源 IP 是否独立。我自己的习惯是先用回显接口跑一个 10 线程的冒烟测试确认 IP 分布符合预期再正式跑业务。如果你拿到的扩展没有线程绑定功能可以用一个取巧方案把 payload 的一部分作为 IP 的输入。比如 payload 是 user001扩展会从 payload 里截取最后三位转成 IP 的第四段这样就实现了「每个 payload 固定一个 IP」。这种改法需要扩展提供模板变量支持没有的话就得自己改源码了。这几步做完你对这个扩展的掌控就从「黑匣子」变成了「可解释的工具」。血泪经验是Fake IP 不是点一下开关就完事的它需要配合业务对 IP 的信任模型来做调整。先把回显接口搭起来再调参最后上并发这套顺序能少踩很多坑。希望帮到你。本文还有配套的精品资源点击获取