企业官网建设流程全解析

1. 先把工具名念对：Fiddler在安卓抓包里到底扮演什么角色

先说个小事。几乎每天都有人搜"Fidder抓包""fildder抓包"，把Fiddler拼成各种奇奇怪怪的样子。这不怪谁，字母顺序确实容易记岔。但如果你正在做安卓手机抓包这件事，工具名可以先放一边，真正要搞清楚的是它在你整个调试链路里站在哪个位置——搞错了位置，后面无论怎么配置都是白忙。

Fiddler本质是一个跑在Windows上的HTTP/HTTPS代理服务器，出自Telerik（后来被Progress收购）。它的经典版本叫Fiddler Classic，还有个跨平台的Fiddler Everywhere。安卓抓包用的最多的是Classic，因为它免费、轻量、脚本能力强。它做的事说人话就是：你让手机的网络流量绕个弯，先经过你电脑上的Fiddler，Fiddler把每一条请求和响应都停下来给你看一眼，甚至可以改一改再放行。它相当于一个"中间信箱"，手机寄出去的信、服务器回过来的信，都要先过它这道手。

这里要纠正一个最常见的新手误解：很多人以为装了Fiddler，手机就能自动被抓包了。不是的。Fiddler默认只监听本机（127.0.0.1），它压根不知道你手机的存在。你必须主动做两件事——让Fiddler允许外部设备连进来，再让手机把代理指向电脑。这两步缺一不可，而且顺序反了会很折腾。

那为什么安卓抓包偏偏这么让人抓狂，而不是像PC浏览器那样直接看？原因有三层。第一层是网络链路：手机和电脑要是不同网段、或者路由器开了AP隔离，流量根本过不来。第二层是代理配置：很多App不老实走系统代理，自己建连接。第三层才是最坑的——HTTPS证书信任，安卓从7.0开始把用户安装的证书单独隔离，App默认不认，于是你能看到请求却看不到内容，满屏的Tunnel to或者CONNECT。这三层每一层都能让你卡上半天。

所以这篇内容我打算按真实的排查顺序来讲。我会先讲清楚Fiddler的工作链路，再手把手把PC端和手机端配通，重点砸在HTTPS证书那道坎上，然后把抓不到包时的完整排查链路摊开给你看，最后加一段实战技巧和工具选型对比。适合正在做App接口调试、前后端联调、测试的同行，也适合第一次接触抓包、被证书劝退过的朋友。我尽量不写教科书式的废话，都是踩过坑之后觉得真正有用的东西。

2. 抓包链路拆解：一次安卓请求从手机到Fiddler要走几步

2.1 代理转发这条主链路是怎么串起来的

要理解抓包，先得把一次完整的请求路径在脑子里画出来。假设你的手机连的是家里WiFi，电脑也连同一个WiFi，电脑局域网IP是192.168.1.100。当你在手机WiFi设置里把代理填成"手动"，主机名192.168.1.100，端口8888，从此手机所有走HTTP代理的流量，目的地就不再是原来的服务器，而是先送到192.168.1.100:8888。Fiddler在那里监听，收到请求后，代替手机去访问真正的目标服务器，拿到应答后再回给手机。

整个过程手机是不知道自己被代理了的（对大多数正常走系统代理的App而言）。Fiddler在这条链路上同时扮演两个角色：对手机来说它是"服务器"，对真正的服务器来说它又是"客户端"。这种"两头都装"的结构，就是中间人代理的本质。理解这一点很关键，因为后面所有的证书问题、连接问题，都是围绕"手机凭什么信任这个中间人"和"中间人能不能连上真服务器"这两件事展开的。

还有一个细节容易被忽略：端口。8888是Fiddler的默认监听端口，你可以在Options里改，但建议新手别改，全网教程默认都是8888，改了之后对不上号反而添乱。如果8888被别的程序占用了（常见于你同时开着某些开发工具），Fiddler会启动报错，这时候要么关掉占用的程序，要么换个端口并同步改手机端配置。

2.2 HTTPS为什么必须靠证书才能解密

明文HTTP的抓包其实很简单，流量过Fiddler，请求头和body直接就能看。但现在的App几乎全是HTTPS，这就麻烦了。HTTPS的核心是TLS加密，手机和服务器之间有一条加密隧道，Fiddler站在中间，看到的就是一堆密文，解密不了。

Fiddler的解法是"伪造身份"。当手机要和某个域名建TLS连接时，Fiddler不是简单转发，而是自己动态签发一张该域名的证书，拿这张证书跟手机握手。手机如果信任了Fiddler的根证书（也就是那张FiddlerRoot.cer），就会认为自己在和真服务器通信，于是把加密数据交给Fiddler。Fiddler用自己签发的证书私钥解开，看到明文，然后再用真服务器的证书去和真服务器建另一条TLS连接。这就是"中间人解密"的完整原理，也是为什么你必须装证书——不装证书，手机不认这张伪造的身份，TLS握手直接失败，你就只能看到一条CONNECT记录，看不到任何内容。

这里有个必须理解的连锁关系：Fiddler的根证书是它自己生成的，每台电脑、每次重装Fiddler都可能不一样。所以证书必须从你正在用的这台Fiddler上导出，不能随便找别人电脑上的证书来装。很多新手从网上随便下载一个FiddlerRoot证书往手机里塞，结果死活不生效，根子就在这。

2.3 安卓端的特殊之处：系统证书与用户证书的隔离

在电脑上，你把Fiddler根证书导入"受信任的根证书颁发机构"，浏览器立刻就认了。安卓早期版本（7.0之前）也是这么简单，装到用户证书里就行。但从**Android 7.0（Nougat）开始，系统做了一个重要改动：App默认只信任系统证书库（System Store）**里的CA，不再信任用户手动安装的证书（User Store），除非App自己在配置里声明要信任用户证书。

这个设计本来是为了安全——防止恶意软件偷偷装个证书来窃听用户流量。但它顺带把正常的调试抓包也一起拦了。于是在7.0之后的手机上抓HTTPS，就出现了经典的分裂场景：浏览器可能还能抓（因为部分浏览器信任用户证书），但绝大多数App抓不了，全是加密隧道。这就是为什么热词里"安卓9刷机""安卓11root"这类词会跟抓包绑在一起——因为网上流传的解法是把证书装进系统证书目录，而那通常需要root权限。这条路我们在第5节会详细讲，并且我会把风险和你真正该走的正规路子分开说清楚。

3. PC端Fiddler的安装与几个必须动过的开关

3.1 安装本身没难度，难点在版本选择

Fiddler Classic的安装确实简单，官网下载一个安装包，一路下一步就行，Windows平台没什么依赖坑。真正要提醒的是版本选择：Fiddler Classic是免费的经典版，功能全、脚本强，安卓抓包绝大多数教程都基于它；Fiddler Everywhere是新的跨平台版，界面现代、支持Mac和Linux，但免费额度有限，且行为和Classic有差异。如果你跟着某篇教程走，第一步先确认对方用的是哪个版本，否则菜单路径对不上会很崩溃。

我个人建议安卓抓包优先用Classic。原因很实在：Classic的HTTPS解密、证书导出、断点调试这些功能成熟稳定，社区资料多，遇到问题一搜就有答案。Everywhere虽然好看，但在处理安卓这种"需要导出根证书给别的设备"的场景上，Classic的操作链路更顺。别被界面颜值带着走，抓包这事稳定压倒一切。

安装完第一次启动，Classic可能会弹一堆提示，比如是否加入客户体验计划、是否配置为系统代理。系统代理这一步很重要——它会把你这台电脑自己的流量也挂到Fiddler上。如果你同时在电脑上调试，就勾上；只想抓手机，勾不勾都行，因为它不影响手机端。但要注意一个副作用：开了系统代理后，电脑上某些不走代理的程序可能连不上网，这是正常的代理行为，关掉Fiddler或取消系统代理就恢复。

3.2 允许远程连接：默认关闭的那个关键开关

装好之后，最容易被忽略的一步来了。Fiddler默认只监听本机回环地址，意味着手机根本连不上。你必须打开远程连接：

打开 Fiddler → Tools → Options → Connections 标签，找到Allow remote computers to connect，勾上它。勾上之后，Fiddler会提示需要重启才能生效，重启一下。

这一步的意义在于，Fiddler的监听地址从127.0.0.1变成了0.0.0.0（即监听所有网卡），手机所在的局域网才能访问到它。很多人卡在"手机连不上代理"，九成是因为这个开关没勾。勾完之后，你可以在Connections面板里看到Fiddler实际监听的端口，默认8888，这个数字记下来，手机端要用。

注意：勾选这个开关后，同一局域网内的其他设备理论上也能连到你的Fiddler。这是个隐私提醒，在公共WiFi（咖啡馆、酒店）下不建议开启，尽量在家里或公司内网这种可信环境操作。抓包调试本来就是看流量的事，环境不干净容易惹麻烦。

3.3 HTTPS解密开关：不勾等于白抓

继续在 Tools → Options 里，切到HTTPS标签，这里有三个关键项：

• Capture HTTPS CONNECTs：勾上。它记录TLS连接的建立过程，即使解密失败，你也能看到连了哪个域名。
• Decrypt HTTPS traffic：勾上。这是解密的核心开关，不勾你只能看到密文。
• Ignore server certificate errors：勾上。有时候目标服务器的证书本身有问题（自签名、过期），Fiddler如果严格校验会中断连接，勾上这个让它放宽，方便调试。

勾选Decrypt HTTPS traffic时会弹出询问是否信任Fiddler根证书的对话框，一路同意。这一步会在Windows的证书库里装上Fiddler的根证书，让Fiddler能顺利代理本机流量。装完之后，你可以在Actions按钮里找到Export Root Certificate to Desktop，把根证书导出来，这就是待会要传到手机上的那个文件。

我强烈建议手动导出证书而不是依赖手机上访问Fiddler下载页面。原因有二：一是通过浏览器页面下载有时会因为证书未信任而报警告，新手容易被吓到；二是导出的文件路径清晰，你知道自己在传什么，后面排查证书问题时心里有数。导出的文件一般叫 FiddlerRoot.cer。

4. 手机端接入：代理设置与第一个包的抓取

4.1 确认网络与IP，别在错网段上折腾

在动手机之前，先在电脑上确认一件事：电脑的局域网IP是多少。打开命令行，敲ipconfig，找到你正在用的那块网卡（WiFi或有线），记下IPv4地址，比如192.168.1.100。这个IP是手机要填的代理地址。

同时确认手机和电脑在同一个局域网。同一个WiFi是最省事的。有个隐蔽的坑：很多家用路由器默认开启了AP隔离（客户端隔离），开启后同一WiFi下的设备之间互相访问不了，手机会连不上电脑的8888端口。判断方法很简单——手机浏览器访问http://192.168.1.100:8888，如果转圈或报错，同时电脑防火墙也确认放行了，那大概率就是AP隔离，需要进路由器后台把它关掉。

还有一个高频问题：Windows防火墙。第一次Fiddler监听外部连接时，Windows会弹窗询问是否允许该程序通过防火墙，一定要选"允许"，且确保专用网络和公用网络都勾上。如果当时点了"取消"，后续手机连不上，就得手动进"防火墙和网络保护 → 允许应用通过防火墙"里把Fiddler放行。这个坑极其常见，症状就是手机代理设了却打不开任何网页。

4.2 手机WiFi代理的具体填法

安卓不同品牌的设置路径略有差异，但大同小异。以原生和大多数国产ROM为例：设置 → WLAN → 长按当前连接的WiFi → 修改网络（或点击WiFi名称旁的齿轮图标）→ 展开"高级选项" → 代理设置从"无"改为"手动" → 主机名填电脑IP（192.168.1.100）→ 端口填8888 → 保存。

保存后，手机的网络就正式挂到Fiddler上了。这时候你打开手机浏览器访问任意网页，回到Fiddler界面，应该能看到左侧一片请求记录唰唰往下滚。看到这一幕，说明代理链路通了，恭喜你完成了最基础也是最容易卡住的一步。

如果没看到任何记录，别急着怀疑证书，先回到第6节的排查链路，逐层确认。这个阶段还没到证书环节，证书只管HTTPS能不能解密，代理本身通不通是另一回事，分清这两个阶段能省很多时间。

4.3 装证书：用浏览器下载还是手动拷贝

代理通了之后，接着装Fiddler根证书。两条路：

第一条，手机浏览器直接访问http://192.168.1.100:8888，Fiddler会返回一个页面，页面上有个链接可以下载FiddlerRoot证书。点它下载，下载完的文件通常是 .cer 或 .crt 格式。

第二条，把电脑上导出的 FiddlerRoot.cer 通过数据线、微信文件传输、网盘等方式传到手机，然后在手机文件管理器里找到它点击安装。

我踩过的坑是：第一条路在部分安卓ROM上会被浏览器的安全策略拦截，提示"无法安装证书"或直接不给下载。这时候第二条路更稳。传文件虽然土，但可控。安装时安卓会让你给证书起个名，随便起个你能认出来的名字，比如"Fiddler调试证书"，然后确认。装的时候系统可能要求你设置锁屏密码/PIN，这是安卓的安全要求（装用户证书需要设备有密码保护），设一下就行，不影响后续。

装完之后，你去"设置 → 安全 → 加密与凭据 → 受信任的凭据 → 用户"里，应该能看到刚装的Fiddler证书。能看到它，说明装成功了。但请注意——装成功不等于抓得到，这就是下一节要讲的7.0信任隔离问题。

5. 安卓7.0以后的证书信任难题：装了证书为什么还是抓不到

5.1 症状识别：CONNECT满屏但没内容

假设你现在代理通了、证书也装了、Fiddler的HTTPS解密也开了，然后打开某个App，发现Fiddler里出现一条CONNECT xxx.com:443，旁边没有请求体和响应体，双击进去也是一片空白或者显示"HTTPS handshake failed"。这就是安卓7.0+最典型的症状。

它的意思是：TLS握手阶段就出问题了，App不信任Fiddler签发的证书，所以拒绝把加密数据交出来，只留下一个连接记录。你在浏览器里可能一切正常（浏览器信任了用户证书），但App就是不认。这不是你配置错了，是安卓故意这么设计的。

为什么偏偏7.0开始？因为从Nougat起，App的网络安全配置默认cleartextTrafficPermitted和证书信任策略收紧，应用默认只认系统CA证书。系统把用户手动装的证书放在了一个App看不到的存储区。这个改动让整个抓包社区哀嚎了好几年。

5.2 正规路子：给你自己开发的App加信任配置

如果你抓的是自己公司或自己开发的App，恭喜你，有一条完全正规、不需要root的路。在App项目的res/xml/目录下创建或修改一个网络安全配置文件，比如network_security_config.xml，内容大致是声明信任用户证书：

<?xml version="1.0" encoding="utf-8"?> <network-security-config> <base-config cleartextTrafficPermitted="true"> <trust-anchors> <certificates src="system" /> <certificates src="user" /> </trust-anchors> </base-config> </network-security-config>

然后在AndroidManifest.xml的<application>标签上加一句android:networkSecurityConfig="@xml/network_security_config"。这样这个App就会信任用户证书（包括你的Fiddler证书），Fiddler就能正常解密了。

这条路的好处是干净、合规、可提交代码、不影响真机其他App。强烈推荐开发同学用这个方式做接口联调。唯一要注意的是，别把这个配置带到生产包里，否则你的App会信任用户恶意安装的证书，存在中间人风险。可以给debug和release配置不同的安全策略，或者只在内部测试包启用。

5.3 需要动系统的场景：root与系统证书目录这条路

现实里，你要调试的可能不是自己的App，而是一个已经打包好的、无法改配置的第三方应用——比如你自己买的某个硬件配套App、或者公司采购的第三方SaaS客户端。这时候改App配置行不通，剩下的办法就是把Fiddler证书装进系统证书目录。

系统证书目录在/system/etc/security/cacerts/，属于系统分区，需要root权限才能写入。这正是为什么"安卓9刷机""安卓11root"这类词会和抓包挂钩。操作思路大致是：手机root后，把Fiddler证书按特定命名规则（通常是证书的hash加 .0 后缀）放进系统证书目录，重启后这个证书就被当成系统级CA，所有App都会信任。

我必须坦率地说几句：root门槛不低，不同机型差异大，操作不当有变砖风险，还可能影响手机保修、支付、银行类App的正常使用。而且这条路只适用于你拥有合法测试授权的场景——比如你自己负责测试的客户端。拿它去窥探不属于你、没有授权的应用流量，既不专业，也可能触碰法律和职业红线。技术是中性的，用在哪里决定了它的价值。作为从业者，我给自己划的线是：只抓我参与开发、或明确获得测试授权的目标。

5.4 还有一层：证书固定（Certificate Pinning）

即便你把证书装到了系统目录，有些App还是抓不到。原因可能是它们用了证书固定（SSL Pinning）：App内部硬编码了它只信任的服务器证书指纹，任何其他证书（哪怕装进系统目录）都直接被拒。这是App开发者主动加的一道防线，用来防中间人攻击，顺带也让抓包变得困难。

遇到证书固定，配置层面基本无解，得从App层介入（比如在开发包里关闭pinning）。对你自己的App，可以在debug构建里关掉固定的逻辑；对没有源码的第三方App，这就不是配置能解决的事了。认识到这个边界很重要——它能帮你判断"是我不够熟练"还是"这条路本来就走不通"，别在一个死胡同里耗一下午。

6. 抓不到包时的排查链路：从连不上到解密失败的逐层定位

抓包失败时最忌讳的就是乱试。我总结了一条分层排查链路，从物理层往上依次验证，每层确认通过再进入下一层，这样能快速锁定问题到底卡在哪。下面这个表是核心，建议对照着看。

先说第一层到第四层，这四层解决的是"数据能不能到Fiddler"的问题，跟证书完全无关。如果Fiddler里一条记录都没有，问题一定在这四层里。排查顺序我一般是这样：手机浏览器访问http://电脑IP:8888，能打开说明网络和防火墙都通；打不开就逐个查AP隔离、防火墙。能打开但Fiddler没记录，就查Allow remote computers和手机代理有没有填对。

第五层开始是"数据到了Fiddler但能不能看懂"的问题。症状是Fiddler里有CONNECT记录但没内容。这一步先确认Decrypt HTTPS勾没勾，再确认电脑上Fiddler根证书装了没（电脑自己调试也要装）。如果电脑上能正常解密，只有手机不行，那就直奔第六层证书信任。

第六层是最硬的骨头。判断依据很简单：同一个HTTPS站点，手机浏览器能抓到明文，App抓不到，基本就是7.0+的用户证书信任问题。这时候要么走App配置（自有App），要么走系统证书（有授权的测试机，需root）。这一步没有捷径，认清目标性质再选路。

第七层证书固定是最后一道关，也是最容易被误判的一层。很多人在第六层折腾半天没用，其实目标App早就做了pinning，配置层面根本无解。识别方法是：日志里能看到TLS握手被拒、证书校验失败的痕迹，且无论你怎么装证书都无效。遇到这种，别硬刚，回到"我是否有权/有必要抓它"这个根本问题上来。

提示：排查时养成一个习惯——每改一个配置就只改一个，改完立刻验证，再改下一个。同时改好几项，成功了你也不知道是哪一项起了作用，下次换个环境又抓瞎。抓包这种高度依赖环境的事，变量控制特别重要。

7. 让Fiddler真正好用：过滤、断点改包与重放

7.1 会话过滤：别让几百条请求糊你一脸

手机抓包和PC最大的区别是请求量爆炸。App一启动，后台的网络请求、埋点上报、图片加载全往上冒，Fiddler左侧列表几秒钟就刷几百条，你想找的那条请求瞬间被淹没。这时候**过滤（Filters）**就是救命功能。

在Fiddler右侧切到Filters标签，勾上 "Use Filters"。最常用的过滤是按主机名：在 "Hosts" 区域的第一个下拉框选 "Show only if URL contains"，然后填上你要盯的域名，比如api.yourapp.com。这样列表里只剩这个域名的请求，清爽多了。还可以按请求类型、按响应码过滤。我调试某个具体接口时，基本都是先把域名锁死，不然眼睛会瞎。

另外提一个实用小设置：Tools → Options → General 里可以设置会话列表的最大条数，默认可能很大。如果你只是短时间调试，把它调小一点，避免内存堆积和列表卡顿。长时间挂着抓包（比如测稳定性）时，记得定期清理会话（Ctrl+X），不然Fiddler吃内存会越来越凶。

7.2 断点改包：调试参数最直接的手段

Fiddler最强大的能力之一是断点（Breakpoint）。它能让请求或响应在Fiddler这里"停住"，你手动改完内容再放行。这在调试接口时太有用了：想测试某个参数传不同值的表现，不用改App代码，直接在Fiddler里改一下请求体。

开启方式有两种。一是菜单 Rules → Automatic Breakpoints，里面能选"Before Requests"（请求发出前断）或"After Responses"（响应回来时断）。二是直接在命令行输入bpu 你要拦截的URL，这样只对特定URL下断点，比全局断点精准得多。请求被拦下后，双击那条会话，在右侧Inspectors里找到请求体，切到"TextView"或"WebForms"改内容，然后点绿色的"Run to Completion"放行。

响应改包同样好使。想验证App对异常数据的处理，可以在响应里把某个字段改掉再放行，看App怎么反应。这个技巧在测试健壮性时特别省事。不过提醒一句：改包调试请在你自己的测试环境里做，别对着生产环境的真实数据乱改，容易造成脏数据。

7.3 重放请求：复现问题的一把好手

接口调试时经常遇到这种情况：某次请求偶发失败，但页面一刷新就复现不了了，抓不到现场。这是**重放（Replay）**功能的用武之地。在会话列表里选中那条请求，右键 → Replay → Reissue Requests，Fiddler会原样再发一次，把响应记录下来。你可以对比两次响应的差异，看服务端是不是偶发问题。

更进一步，右键菜单里还有"Reissue and Edit"，重放前先改点东西。这在你需要批量构造相似请求时很好使。配合前面讲的断点，能组合出一套相当灵活的调试玩法。我做过最实用的一个组合是：先过滤出某接口，然后用重放功能连续打几十次请求，观察响应时间分布和成功率，快速判断服务端稳不稳。这些操作都不用写一行代码，纯Fiddler里点几下就搞定。

8. 抓包工具选型：Fiddler、Charles、Wireshark各管哪一摊

用久了你会发现，抓包工具不是只有一个，每个都有自己的地盘。聊聊选型，能帮你少走弯路。

Fiddler的优势在于Windows原生、免费、脚本能力强（FiddlerScript可以写C#逻辑自动处理请求）、断点和改包体验顺滑。它的短板是官方主推的Everywhere收费，Classic虽然免费但只跑Windows，界面也偏老派。做安卓App接口调试，Classic依然是性价比最高的选择。

Charles是Mac用户的老朋友，跨平台（Mac/Win/Linux都有），界面比Classic友好，HTTPS配置逻辑和Fiddler类似。它的代理配置、Map Local、Rewrite这些功能设计得挺顺手。收费，但有试用。团队里如果混用Mac和Windows，Charles的一致性更好，不用每台机器装不同工具。

Wireshark是另一个维度。它工作在网络层，抓的是原始数据包（PCAP），不做HTTP层的解密（除非你配置了TLS密钥）。它的强项是分析底层协议——TCP重传、握手细节、非HTTP的流量（比如自定义TCP协议、DNS查询、802.1x认证流程等）。当Fiddler帮不了你、你需要看网络底层到底发生了什么时，Wireshark才登场。它的门槛比Fiddler高不少，但对排查"连接建立失败""协议不是HTTP"这类问题无可替代。

简单给个选型思路：调试App的HTTP/HTTPS接口，用Fiddler或Charles；排查底层网络、非HTTP协议，用Wireshark。热词里出现的bp（Burp Suite）、Reqable这些，更多偏向安全测试和更现代的界面，思路类似，选一个顺手的深入即可，工具换太多反而分散精力。我自己的组合是Fiddler做日常接口调试，偶尔需要看底层协议时开Wireshark，两把刷子够用了。

关于安卓抓包这件事，我最后再分享几个只有实操才能攒出来的经验。第一，固定一套可信的网络环境，别在公共WiFi折腾，既是隐私问题也是连通性问题，家里或公司内网最省心。第二，把IP设成静态或用固定设备名，路由器重启后DHCP可能给你的电脑换IP，手机代理里填的还是老IP，自然连不上，排查半天才发现是IP变了。第三，证书是有有效期的，Fiddler默认根证书有效期挺长，但如果你重装过Fiddler或者换过电脑，证书得重新导一次。第四，调试完记得把手机WiFi代理关掉，不然你手机会一直连不上网（因为代理指向的电脑关了或换了网络），很多人第二天发现手机没网就是忘了这茬。抓包这套东西，配置占三成，排查占七成，把链路原理吃透，剩下的就是经验积累了。