企业官网建设流程全解析

抓包工具这四个字，很多人第一次听到是在排查一个“代码明明没写错、接口就是返回不对”的下午。那一刻你会发现，日志打了十几行、断点停了好几遍，问题依然像隔着一层毛玻璃——真正有价值的信息不在你的代码里，而在客户端和服务端之间那条来回穿梭的链路上。抓包工具就是把这层毛玻璃擦干净的东西：它把请求和响应原原本本摊在你面前，让你看见请求头里多了个字段、响应体被压缩成了乱码、某个接口被重定向了三次、某个静态资源卡了八秒。

这篇文章整理的十款主流抓包工具，覆盖桌面代理型、命令行网卡型、浏览器内置型三大类，从零基础能直接上手的一键式工具，到服务器上只能靠一行命令搞定的底层工具，都会讲清楚它们各自适合什么场景、为什么适合、有哪些坑。适合谁看？前端、后端、测试、运维、客户端开发，以及需要对自己负责的系统做安全合规自测的同学。所有内容的前提只有一个：你抓的是自己的系统，或者你已经拿到了明确的书面授权。这条线踩不得，后面会单独用一节讲清楚边界。

1. 抓包这件事，先把它在抓什么讲明白

1.1 抓包的本质：在数据必经之路上放一个观察点

很多人对抓包的理解停留在“点一下开始，网络请求就自动出现了”，这会导致后面遇到抓不到的情况时完全无从下手。要理解抓包，先要理解数据是怎么流动的：你的应用发起一个请求，数据从应用层往下走，经过传输层、网络层、链路层，最后从网卡出发，穿过路由器、交换机，到达服务端，再原路返回。

抓包工具能起作用，本质上是它想办法把自己塞进了这条路径的某个位置上。塞的位置不同，决定了工具的能力边界，也决定了它会遇到什么限制。目前主流工具塞位置的方式有三种：第一种是充当代理，让客户端的流量主动经过它；第二种是直接监听网卡，把链路上流过的每一个数据帧都复制一份；第三种是寄生在应用内部，比如浏览器自带的开发者工具，它拿到的本来就是应用层已经解析好的数据。

这三种方式没有优劣，只有适配场景。代理型能改请求、能断点、能重放，是接口调试的主力；网卡型看不到加密内容但能看到全貌，是排查“到底有没有发包”“握手卡在哪一步”的利器；内置型零配置，随手就能开，但只能在那个应用里用。搞懂这个分类，你在遇到问题时就能第一时间判断“这个需求该用哪一类工具”，而不是把所有工具都试一遍。

我用一个生活化的类比：代理型像是你在自家门口装了个快递代收点，所有包裹都要经过它，它能拆开看、能改地址、能拍照留底；网卡型像是在小区门口的监控探头，谁进谁出一目了然，但人家把包裹封得严实你就看不见里面；内置型则是快递公司自己的系统后台，信息最全，但只对自家业务有效。

1.2 三类抓包方式的边界：为什么有些包注定抓不到

理解了原理，就很容易解释那些“抓不到”的困惑。代理型工具抓不到包，最常见的原因是客户端压根没走代理：有的应用自己实现了直连逻辑，有的用了长连接复用了已有通道，还有的把代理配置写死在代码里。这时候你在工具里看半天一个请求都没有，不是工具坏了，是流量根本没从这过。

网卡型工具的边界更明显。它能看到 TCP 三次握手、能看到 TLS 握手时协商了哪个版本哪个套件、能算出重传率和往返时延，但 HTTPS 的内容对它来说就是一段密文。想解密也不是没办法，浏览器和部分运行时支持把会话密钥导出到文件，抓包工具读取这个文件就能还原明文，这个机制在排查“客户端和服务端到底谁先出错”时非常好用，前提是你能控制被测程序的启动参数。

还有一个经常被忽略的边界：本地回环流量。有些工具默认不监听 loopback，你本地起了个服务、本地调本地，抓包界面干干净净。这时候要么换工具，要么在工具设置里显式打开回环监听。这个坑我在早期踩过不止一次，排查了半小时以为是代码问题，最后发现是工具没配。

提示：任何时候开始抓包前，先问自己三个问题——流量走不走代理？内容是不是加密的？目标是不是本机回环？这三个答案基本能决定你该选哪类工具，能省掉大量试错时间。

1.3 HTTPS 为什么需要“信任一张证书”才能看清内容

这是新手最容易卡住的一环，也是最需要讲清楚原理的一环。HTTPS 的加密是端到端的，客户端和服务端各自协商出一个只有双方知道的密钥，中间的任何人拿到数据都只能看到密文。代理型抓包工具想要看到明文，就必须让自己成为“双方都认识的人”——它对客户端冒充服务端，对服务端冒充客户端，两端各建一条加密通道，中间这段明文就落在工具手里了。

要让客户端认它，工具需要给自己签发一张根证书，你把这张根证书装进操作系统或浏览器的信任列表里。从此客户端看到工具签发的站点证书时，会顺着证书链找到这张根证书，校验通过，握手正常完成。这就是为什么几乎所有代理型工具的第一步操作都是“下载并安装根证书”，没装证书的表现也很典型：浏览器弹安全警告、应用直接报网络错误、工具里显示握手失败。

这里要多说一句，不同系统对证书的信任策略差异很大。桌面系统装进系统信任区基本就生效；移动端装完描述文件后，还要单独去“证书信任设置”里手动打开开关，这个开关藏在设置深处，很多人漏掉。而较新版本的移动系统对应用信任哪些证书做了更严格的限制，普通用户证书可能不被某些应用采信，遇到这种情况正确的做法是找开发要一个开了调试开关的测试包，而不是去折腾设备本身，既省事也更规范。

2. 十款主流工具横向拆解：按场景选，别按名气选

2.1 桌面代理型五款：日常接口调试的主力部队

这一类是绝大多数人真正每天要用的。它们的共同特点是装完就能用、有图形界面、能改请求能重放，适合接口联调、参数验证、线上问题复现。

Fiddler是 Windows 阵营的老牌选手，经典版本免费且功能完整，会话列表、断点、请求构造器、性能统计一应俱全。它的强项在于对 Windows 生态的贴合，系统代理自动接管，装上就能抓。新版走订阅制，跨平台支持更好，但对只做基础调试的人来说经典版足够。初学者最该先掌握的是它的过滤功能，默认会把你机器上所有进程的请求都列出来，不设过滤根本没法看。

Charles是跨平台的经典选择，界面逻辑清晰，把请求按域名树状归类，看多域名混合的页面时特别舒服。它的 Map Local 和 Rewrite 功能是杀手锏：前者把某个远程资源映射成本地文件，改前端样式不用等后端；后者能按规则批量改写请求头响应头，模拟各种异常返回。缺点是基于 Java，启动慢、内存占用偏高，长时间开着挂机容易卡。

Proxyman是近年在苹果生态里口碑很好的一款，原生开发、启动快、交互流畅，对 HTTP/2 和 WebSocket 的支持做得扎实。它的证书安装流程做得极其顺手，一键装到模拟器或者真机，省掉大量手工步骤。如果你主力机是 Mac，做客户端调试，这款的体验会比跨平台的 Java 系工具好一截。

Whistle是国内开发者做的一款基于 Node 的代理工具，界面是网页版，配置全部通过规则文件完成。它的核心优势是规则表达能力极强，一条规则就能完成“把 A 域名的请求转发到 B 地址并改掉请求头”这种组合操作，适合需要长期维护一套复杂调试环境的人。命令行启动、浏览器打开控制台即可，团队里共享一份规则文件也很方便。

Reqable是近几年起来的国产新秀，把抓包和接口调试揉在了一起，界面现代化，移动端配套做得比较完整，安卓端可以直接在设备上抓。它的定位偏向“一站式的接口工作台”，如果你既想抓包又想顺手测接口，可以把它当主力试试。

这五款怎么选？一句话：Windows 上量大管饱选 Fiddler，跨平台求稳选 Charles，Mac 原生体验选 Proxyman，需要写规则做复杂转发选 Whistle，想要抓包加接口测试一体化选 Reqable。真要较真，装两款就够覆盖 95% 的场景。

2.2 命令行与网卡层三款：服务器和底层问题的专属武器

图形界面在服务器上是不存在的，很多时候你只有一台黑乎乎的终端。这三款工具就是为这种场景准备的。

Wireshark是网卡层抓包的事实标准，能力深不见底。它抓的是链路层的原始帧，所以 TCP 重传、窗口大小、TLS 握手细节、DNS 解析耗时，全都能看得一清二楚。它的过滤语法必须掌握，否则几万个包会让你直接放弃。常用表达式就那么几个：按端口tcp.port == 443，按地址ip.addr == 10.0.0.5，按域名http.host contains "api"，组合用and连接。它还能直接读取 tcpdump 抓下来的 pcap 文件，属于“本地分析”这一环的最佳选择。

tcpdump是服务器上的标配，几乎所有的 Linux 发行版都自带，不用装任何东西。它的价值在于能在生产环境用极低开销抓一小段流量出来。典型命令是tcpdump -i any -nn port 8080 -w cap.pcap，抓完把文件拉回本地用 Wireshark 打开分析。这里有个经验：生产环境抓包一定要加-s控制每个包的截断长度，并且限定端口和主机，否则几分钟就能抓出几个 G，磁盘直接告急。

mitmproxy是命令行代理型工具里的异类，它既有交互式终端界面，又能写 Python 脚本对流量做任意处理。当你需要“把所有响应里的某个字段批量改掉”或者“统计某类请求的耗时分布”时，写十几行脚本比在图形界面里点一百次强得多。它还支持把抓到的流量导出成可回放的格式，做自动化回归的时候很顺手。

这三款的学习曲线明显比图形工具陡，但我建议每个后端和运维同学至少把 tcpdump 和 Wireshark 的组合练熟——线上出现“偶发超时”这类问题时，日志往往什么都看不出来，只有抓到的那几十个包能告诉你真相。

2.3 浏览器内置与其他两款：随手就能开的轻量选择

不是所有场景都值得装一个工具。有些问题，浏览器自带的面板就解决了。

Chrome DevTools 的 Network 面板是零成本的首选。F12 打开，勾上 Preserve log，刷新页面，每个请求的耗时分解、请求头响应头、请求体响应体、Cookie、发起者调用栈全在里面。它的 Timing 面板能把一个请求拆成 DNS 查询、TCP 连接、TLS 握手、等待响应、内容下载五段，排查“为什么这个接口慢”时，一眼就能看出是网络问题还是服务端处理慢。缺点是它只能看浏览器内的流量，且对已经发生的请求无法重放（新版加了重放能力但有限制）。

HTTP Toolkit的亮点是“一键拦截”，它能自动帮你启动一个配置好代理的浏览器或应用实例，证书也自动装好，对完全零基础的人来说门槛最低。它同样支持安卓设备的抓包引导，适合临时要看一眼某个 App 在发什么请求的场景。

Stream是移动端专用的轻量工具，直接在手机上运行，不需要连电脑，装个描述文件就能抓本机的流量。排查“这个 App 在我这台机器上为什么登录不上”这类问题时，掏出手机就能看，非常高效。

补充一个经常被低估的：Postman 的 Console。你在 Postman 里发的每个请求，原始报文都记录在控制台里，排查“我明明传了参数为什么服务端收不到”时，看这里比看界面表单靠谱得多。

2.4 选型对照表与决策路径

光看文字描述容易晕，直接上表。

决策路径其实很短：先问“我要不要改请求”。要改，走代理型；不改只想看底层，走网卡型。再问“我在哪台机器上”。服务器上只有命令行，桌面端优先图形界面。最后问“目标是不是浏览器里的网页”。是的话先按 F12，能解决就别折腾别的。按这个顺序走，九成的选择困难会在三十秒内消失。

3. 从零搭一条完整的抓包链路

3.1 环境准备与代理链路搭建

假设你要抓一台手机上的应用请求，这是最常见的完整链路。整个链路是这样的：手机 → 电脑上的代理工具 → 目标服务器。手机和电脑必须在同一个局域网里，电脑的防火墙要放行代理端口。

第一步，在电脑上启动代理工具，找到它监听的端口。各工具默认端口不太一样，Fiddler 和 Charles 都是 8888，mitmproxy 是 8080，Whistle 是 8899，Proxyman 是 9090。这个端口记下来，下一步要用。

第二步，查电脑在局域网里的地址。Windows 上ipconfig看 IPv4 地址，macOS 和 Linux 上ifconfig或ip addr。注意别选成虚拟网卡（比如虚拟机或容器创建的那些），要选你实际连着路由器的那个网卡。

第三步，在手机的 Wi-Fi 设置里，把当前网络的代理改成手动，主机名填电脑的 IP，端口填工具的端口。保存后打开浏览器随便访问一个网页，回到电脑上的工具界面，应该能看到请求冒出来了。看不到就往下看第 4 节的排查表。

这里有个细节值得强调：改代理会影响整台设备的网络，抓完记得改回“关闭”。我见过有人抓完忘了改，第二天换了个网络环境，手机死活上不了网，排查了半天才发现是代理还指着那台已经关机的电脑。

另一个细节是端口冲突。8888 这个端口太常见，有时候会被别的程序占着，工具启动时会提示绑定失败。换一个不常用的端口就行，比如 8899 或 9091，改完记得同步改手机上的设置。

注意：如果你是远程办公、电脑和手机不在同一网段，这套链路是搭不起来的。这种情况下的正确做法是把应用装到本机的模拟器里抓，而不是去折腾网络结构。

3.2 根证书安装：决定你能不能看到明文的临门一脚

代理配好之后，你打开一个 HTTP 站点能看到明文，打开 HTTPS 站点却只能看到一串Tunnel to ...:443，这就是证书还没装。整个流程分两步：下载证书、装进信任区。

下载方式各工具不同，但基本都能通过访问一个特殊地址拿到。Fiddler 是浏览器访问http://localhost:8888，页面上有下载链接；Charles 在菜单里找 SSL Proxying 相关的保存证书选项；mitmproxy 的证书默认落在用户目录下的.mitmproxy文件夹里，文件名类似mitmproxy-ca-cert.pem。拿到文件后发给手机，或者手机直接访问电脑的 IP 加端口下载。

装证书这块，各平台差异必须说清楚，因为这是新手卡壳率最高的地方：

• Windows：双击证书文件，选择安装到“受信任的根证书颁发机构”，一路下一步。装错了位置不会生效，这一点要特别注意。
• macOS：双击导入“钥匙串访问”，找到这张证书，双击打开信任设置，把“使用此证书时”改成“始终信任”。
• iOS：通过 Safari 下载描述文件，去设置里安装，装完之后还必须进“通用 → 关于本机 → 证书信任设置”，把对应开关打开。这一步漏掉的人非常多，表现为证书装完了但还是抓不到明文。
• Android：在设置里搜索“证书”，从存储设备安装，选“CA 证书”。较新版本的系统会把用户安装的证书和系统证书区分对待，部分应用只信任系统证书，这时候抓不到明文属于正常现象。

关于最后这种情况，我要明确一个态度：正规做法是让开发提供一个允许调试证书的测试包，或者直接在测试环境用明文 HTTP 验证逻辑。去折腾设备系统本身既不必要，也可能带来其他风险，而且是很多人把简单问题复杂化的开始。

3.3 过滤规则与抓包现场记录

证书装通之后，你会面临第二个问题：信息太多。一个页面加载几十个请求，一个 App 启动上百个请求，不设过滤你根本找不到想看的那一条。

过滤的思路分三层。第一层按域名或路径过滤，这是最常用的。Fiddler 的 Filters 面板可以只显示指定 Host；Charles 有 Focus 功能，右键一个域名选 Focus 就只看它；Whistle 直接在规则里写匹配模式；mitmproxy 用~u 关键词这样的流过滤器。第二层按请求类型过滤，比如只看 XHR、只看 WebSocket。第三层按状态码过滤，排查错误时只看 4xx 和 5xx，列表瞬间清爽。

如果用的是 Wireshark 或 tcpdump，过滤语法是另一套。tcpdump 的写法是tcpdump -i any -nn -s 200 host 10.0.0.5 and port 8080，其中-s 200表示每个包只保留前 200 字节，够看头部信息，又能把文件体积压下来。Wireshark 的显示过滤器更丰富，tcp.analysis.retransmission直接筛出重传包，http.response.code >= 500筛出服务端错误，这些都是排查性能问题时的常用起手式。

抓包现场记录这件事，值得单独提醒。很多人抓完一堆包，回头分析时完全想不起来“这个请求是我在哪个操作之后发出的”。正确做法是抓包过程中同步记时间点：几点几分点了哪个按钮、几点几分提交了哪个表单。工具里都有给请求加注释或者标颜色的功能，遇到关键请求立刻标一下，事后能省掉大量猜测。

另外，抓包文件要随手保存。Fiddler 和 Charles 都能导出会话，Wireshark 和 tcpdump 生成 pcap 文件。文件名带上日期和场景，比如20250312-login-fail.pcap，比新建文件夹(3)强一万倍。

3.4 把抓到的报文变成结论：分析的三条主线

抓到包只是开始，看懂才是目的。我一般按三条主线切入。

第一条是请求参数线。对比一个成功请求和一个失败请求，逐字段看差异：某个必填参数是不是空的、某个枚举值是不是传错了、Content-Type 是不是和实际格式对不上、时间戳和签名是不是过期了。这类问题在联调阶段占了一半以上，而且往往看一眼就能定位。有一个特别隐蔽的坑是字符编码：前端传了中文，抓包看到的是%E4%B8%AD这样的转义，解出来和实际不一致，就要怀疑是不是两端编码约定不同。

第二条是响应结构线。看状态码、看响应头里的 Content-Type 和 Content-Encoding、看响应体是不是被压缩成了二进制。很多人看到响应体是一堆乱码就以为出错了，其实是 gzip 或 brotli 压缩，在工具里开启自动解压就能看到原文。还有一个常见情况是响应体正常但业务报错，这时要去翻响应头里的链路追踪字段或者业务错误码，往往能直接指向具体原因。

第三条是时序性能线。把请求按时间排序，看整体的瀑布流。哪一段耗时最长、有没有串行的请求本可以并行、DNS 查询是不是每次都重来、TLS 握手是不是重复发生。DevTools 的 Timing 面板和 Charles 的图表都能直观呈现。我遇到过一个问题：页面打开要八秒，日志里每个接口都是几十毫秒，最后靠瀑布流发现是某个第三方统计脚本卡在加载中，阻塞了后面的关键请求。这种问题不抓包是永远看不出来的。

4. 踩坑实录：抓不到、看不懂、连不上怎么排

4.1 抓不到包的五类原因速查

这是被问得最多的问题，我整理成一张表，按出现频率排序。

再补充几个表里放不下的经验。一是 IPv6 的坑：有些网络环境下设备优先走 IPv6，而工具只监听了 IPv4 的代理端口，表现就是部分请求抓得到部分抓不到。这种情况在工具设置里确认监听地址，或者临时关闭设备的 IPv6。二是休眠唤醒后代理失效，笔记本合盖再打开，代理进程还在但网络栈重连过，代理设置可能被重置，重启一次工具基本能恢复。

还有一个很隐蔽的情况：某些应用的网络请求走的是独立的网络库，不读系统代理设置。这时候你无论怎么改系统代理都不会有反应。判断方法很简单，用网卡层工具抓一下，如果确实有流量在跑但代理工具里没有，基本可以确认。解决方向不是死磕代理，而是换工具或者让开发在测试包里显式指定代理。

4.2 报文看不懂的三类解码问题

抓到了但看不懂，比抓不到更让人抓狂，因为你会怀疑自己是不是抓错了。

第一类是压缩问题。响应头里有Content-Encoding: gzip或br，但工具没解压，响应体显示成乱码。多数工具默认会自动解压，但在某些场景（比如你手动改了请求头把 accept-encoding 去掉了）会失效。这时在工具里找到解压相关选项打开，或者把抓到的内容复制出来单独解压。

第二类是协议版本问题。HTTP/2 是二进制分帧的，某些工具的旧版本会把它显示成一堆看不懂的十六进制。遇到这种情况先确认工具版本，新版本基本都支持，或者临时在客户端禁用 HTTP/2 用 HTTP/1.1 复现一次。WebSocket 的帧也需要单独的面板来看，普通请求列表里只能看到握手那一条。

第三类是编码问题。响应体显示成\u4e2d\u6587这样的转义，或者中文变成问号。前者是 JSON 里的 Unicode 转义，属于正常现象，工具里一般有格式化选项；后者通常是字符集声明和实际编码不一致，去看响应头里的 charset 和实际字节流比对一下。

提示：遇到看不懂的响应，先看响应头三件套——Content-Type 告诉你是什么格式，Content-Encoding 告诉你有没有压缩，Content-Length 告诉你长度对不对。这三个字段能解决大半的“看不懂”问题。

4.3 移动端与模拟器的典型故障

移动端抓包是问题最集中的地方，单独拎出来说。

手机连不上网但代理工具没反应。大概率是代理地址填错了，或者电脑防火墙拦了。先在手机浏览器访问电脑的 IP 加端口，如果能看到工具的管理页面，说明链路是通的，问题在别处；如果打不开，就是网络层的问题，检查是不是同一网段、是不是填了虚拟网卡的地址。

证书装了还是抓不到 HTTPS。iOS 上九成是忘了打开证书信任开关；Android 上则要看系统版本和应用对证书的信任策略，前面讲过，正规做法是让开发给测试包。

模拟器里的流量抓不到。很多模拟器有自己的网络模式，比如 NAT 模式下模拟器内部是个独立网络，系统代理设置可能不生效。常见的处理方式是在模拟器设置里找到代理选项直接填，或者在模拟器内部装一个代理配置工具。另外要注意，模拟器访问宿主机一般要用一个特殊地址，而不是127.0.0.1。

抓到的请求时间和实际操作对不上。这是设备时间不同步导致的，抓包工具的时间戳来自设备，如果你的手机时间比电脑慢了几分钟，瀑布流会看起来很奇怪。抓包前顺手把设备时间设成自动同步，能省掉这类困惑。

5. 边界与自律：抓包这件事的护栏在哪

5.1 授权范围决定一切，技术能力不是通行证

抓包这个技能本身是中性的，它和所有调试手段一样，价值取决于用在哪。我的原则很简单：只抓自己负责的系统，或者拿到了明确书面授权的系统。公司内部的测试环境、自己开发的应用、参加授权的安全自测项目，这些都没问题。别人的系统、来路不明的应用、公共网络里的陌生流量，一律不碰。

授权不只是“口头说可以”，而是要明确三件事：范围（哪些域名、哪些接口）、时间（什么时候到什么时候）、数据处置方式（抓到的数据存哪、什么时候删）。这三件事没说清楚，就不要开始。我见过团队里因为抓包数据里混进了真实的用户信息，最后不得不做一次完整的数据清理和上报，成本远高于收益。

另一个容易被忽略的点是生产环境。在生产上抓包和在测试环境抓包，性质完全不同。生产流量里可能有真实的业务数据，抓之前必须评估必要性，能脱敏就脱敏，能限定条件就限定条件，能缩短时间就缩短时间。

5.2 数据最小化与及时清理，是专业度的体现

抓包文件里往往包含完整的请求头，里面可能有身份凭证、会话标识、设备信息。这些东西一旦落到不该落的地方，后果比大多数 bug 都严重。我的习惯是三条：抓包时就用过滤规则把无关域名排除掉；分析完立刻删掉原始文件，只保留脱敏后的截图或文字记录；需要长期保存的样本，先做字段替换再归档。

团队协作时更要注意。把抓包文件发到群里让人帮忙看，是很常见的操作，但发之前要过一遍内容。有没有带了真实用户信息的响应体、有没有带了内部地址的请求头、有没有带了凭证的 Cookie，删掉这些再发。这个动作花不了两分钟，但能避免很多麻烦。

工具本身也提供了不少辅助能力，比如会话导出时可以选择只导出请求头、可以批量替换敏感字段、可以设置不记录某些域名的流量。这些功能平时看着不起眼，真到了需要给别人分享分析结果的时候，就知道有多重要。

6. 一些提高效率的实操习惯

前面讲的都是“怎么做对”，这一节讲“怎么做快”。这些习惯没有技术门槛，但能明显缩短排查时间。

第一个习惯是建一套固定的调试环境。我电脑上常驻一个代理工具，规则里预先配好测试环境、预发环境、本地服务的转发，需要切换的时候改一行规则就行，不用每次重新配。团队里把这套规则文件共享出来，新人入职直接导入，能省掉大量“我这怎么抓不到”的沟通。

第二个习惯是用断点代替改代码。要验证一个边界情况，比如接口返回空数组时页面会怎样，不需要去后端改代码，直接在工具里对这个接口下断点，把响应体改掉再放行。Charles 的 Rewrite、Fiddler 的断点、mitmproxy 的脚本都能做到。这个技巧在验证前端容错逻辑时特别好用。

第三个习惯是把高频问题做成速查表。我电脑旁边贴着一张纸，上面写着常用的过滤表达式、常用端口、证书安装路径。听起来很土，但排查问题的时候不用现查文档，效率差别很大。

第四个习惯是抓包和分析分离。在服务器上抓，抓完把文件拉回本地分析，而不是在生产机器上装图形界面。这个习惯既是效率考虑，也是稳定考虑——生产机器上跑的东西越少越好。

第五个习惯是记录结论而不是记录过程。抓完一次包，把结论写进问题单里：哪个接口、什么参数、什么现象、根因是什么。原始抓包文件删掉，结论留下来。半年后有人问起同样的问题，翻记录就能找到，不用重新抓一遍。

我个人在实际操作中的体会是，抓包这个技能真正的门槛不在工具，而在“知道该看什么”。工具的操作半天就能学会，但能不能从几十个请求里一眼揪出那个异常的，靠的是对系统架构的理解和大量的排查经验。所以我建议新入门的同学，别急着把十款工具都装一遍，先挑一款用得顺手的，把它用透，在真实问题里反复练，比什么都管用。等你对“请求应该长什么样”有了直觉，换任何工具都是半小时的事。