FRP使用Fiddl

本文目录导读：

1. 为啥非要FRP配合Fiddler？这不是找虐吗？
2. 我的实操过程：一步步破解抓包难题
3. 真实案例分享：我是如何抓到一个诡异的404
4. 可能还会踩的坑（我都替你们试过了）
5. 总结：FRP用Fiddler抓包，效果简直绝了

FRP使用Fiddler抓包？天呐！原来内网穿透还能这样调试！别再瞎折腾了！

哎哟喂,各位老铁们，今天咱们来聊聊一个让我最近又爱又恨的技术组合——FRP使用Fiddler调试，说实话，我刚开始接触这个的时候，整个人是崩溃的！明明FRP配置得好好的，Fiddler也正常开着，可就是抓不到内网穿透的包，这谁受得了啊？不过经过我连续几个晚上死磕，总算把这俩“神仙”给凑一块儿了，今天必须写篇文章，把我踩过的坑和最后搞定的方法全都倒出来，省得你们再走弯路！

为啥非要FRP配合Fiddler？这不是找虐吗？

咳咳,先说说我的真实使用场景吧，前几天接了个项目，需要远程调试客户公司内网的一台服务器上的Web应用，那环境，局域网IP，没有公网地址，防火墙还贼严格，这时候FRP（Fast Reverse Proxy）就派上大用场了，它能通过一台有公网IP的VPS做中转，把内网服务映射到公网，但是问题来了——调试接口的时候，我看不到完整的HTTP请求和响应啊！这时候就需要Fiddler这个抓包神器登场了。

可是,FRP用Fiddler抓包，这事儿听着简单，做起来真是处处是坑，我把我的解决方案分享出来，你们可记好了！

我的实操过程：一步步破解抓包难题

第一步：环境准备（这里我差点就放弃了）

我当时的配置是这样的：内网机器（部署Web服务）+ 公网VPS（运行frps）+ 本地电脑（运行frpc和Fiddler），按理说，本地发起的请求经过Fiddler代理，再通过frpc转发到VPS，VPS再到内网服务，数据流应该是：浏览器 → Fiddler → frpc → frps → 内网服务。

可是！问题是frpc默认是不走系统代理的！我一开始用浏览器设置了Fiddler的代理（127.0.0.1:8888），结果流量全都进了Fiddler，但frpc压根不理会这个代理设置，我盯着Fiddler里空荡荡的列表，心里那个急啊，差点就准备放弃用Fiddler了，哼，我就不信这个邪！

第二步：给frpc装上“眼睛”（也就是设置代理）

既然frpc不认系统代理,那咱得手动给它指定代理地址，解决办法是在启动frpc的命令行里加上代理参数，或者更简单点——在frpc的配置文件里设置，呐，具体是这样的：

在frpc.ini的[common]部分添加一行：

http_proxy = http://127.0.0.1:8888

啊哈！就这么简单？我当时还真就愣了，赶紧重启frpc，再去Fiddler看，咦？还是有流量没进来？别急，还有个好戏在后头。

其实光设置http_proxy还不够,因为有些版本的frpc是用Go语言写的，它默认使用的代理配置是HTTPS_PROXY环境变量，而不是http_proxy，所以啊，你得在命令行里同时设置两个环境变量：

set HTTP_PROXY=http://127.0.0.1:8888
set HTTPS_PROXY=http://127.0.0.1:8888

然后再启动frpc,这下Fiddler里终于开始刷屏了！我当时激动得差点跳起来，终于能看到内网穿透的HTTP请求细节了。

第三步：别忘了Fiddler自己的解密设置

为什么这里还要提一嘴？因为如果你调试的HTTPS接口，Fiddler默认是无法解密HTTPS内容的，你需要开启“HTTPS解密”功能：打开Fiddler → Tools → Options → HTTPS tab → 勾选 "Capture HTTPS CONNECTs" 和 "Decrypt HTTPS traffic"。

我当时没勾选,看到一大串SSL握手信息，全乱码，还以为frpc配置又出错了呢！你们可别犯傻，提前勾好，而且要信任Fiddler生成的根证书，不然有些程序不认，不过咱是调试自用，勾选信任就行。

真实案例分享：我是如何抓到一个诡异的404

记得有次,用FRP映射客户内网的某个API接口，前端始终报404，我在本地死活复现不了，用FRP+Fiddler抓包后，好家伙，原来Request的Header里居然带了一个奇怪的X-Forwarded-For参数，客户内网nginx根据这个参数做了IP白名单，导致请求被拒，如果没有Fiddler看到完整请求头，我可能一天都在瞎猜，真是谢谢Fiddler救命了！

可能还会踩的坑（我都替你们试过了）

1. 端口冲突：Fiddler默认监听8888端口，如果你本地的frpc也用了8888做代理端口，那肯定会冲突！我还遇到过Fiddler崩溃的，结果发现是frpc占用了端口，所以你们用8080、8888这种常见端口时，一定要先检查有没有被别的程序占用。

2. 浏览器缓存干扰：有时候你明明改了代码，但浏览器还走缓存，抓包看到的是旧请求，这时候强制刷新页面（Ctrl+F5）或者清理缓存，再来抓包。

3. 连接被拒绝：如果Fiddler里出现 [Fiddler] Connection to 127.0.0.1 failed，八成是因为Fiddler作为代理转发给frpc时，frpc没有正确监听，你需要确认frpc的local_ip和local_port是否和Fiddler要转发的一致，这个我也坑过，差点郁闷死！

FRP用Fiddler抓包，效果简直绝了

好了,说了这么多，你们应该明白FRP配合Fiddler做调试有多强大了，它让我能在本地看到内网穿透的所有请求细节，不管是调试接口、排查问题，还是分析他人的恶意请求，都清楚得很，虽然配置过程中有那么点反人类，但一旦搞定了，那成就感真的是杠杠的！以后我再也不用盲人摸象似的去猜测内网服务到底返回了什么了。

最后再提醒一句：网络安全不仅仅停留在白帽子领域，咱们自己写代码、部署服务，也得学会用工具去排查和分析，FRP结合Fiddler，就是你调试内网服务的利器！希望你们别像我当初那样被坑得怀疑人生，顺利掌握这套调试大法！

想深入学习网络安全？随时可以加QQ，一起交流抓包、渗透、攻防技术！咱们互相学习，共同进步！

呢,就是我这个老网工摸爬滚打出来的经验之谈，如果你们在操作中遇到什么问题，或者有更好的方法，欢迎私信探讨，别忘了加QQ哦，我们下期再见！