这是个非常典型的移动APP代理拦截问题，我来拆解背后的核心原因，以及你可以用来验证的方法——毕竟你只是想搞懂机制，不是要解密内容：

1. APP主动绕过系统代理配置 #

很多主流社交APP（包括WhatsApp）都会刻意忽略系统级的代理设置，不走设备全局配置的HTTP/HTTPS代理。它们在代码里会强制使用直连（direct connection），甚至硬编码DNS解析结果、直接发起TCP/UDP连接，完全不遵循系统的代理路由规则。这就是为什么你的Safari能被正常捕获，但WhatsApp功能正常却看不到任何流量——它根本没走你设置的mitmproxy。

2. 核心功能使用非HTTP/HTTPS协议 #

WhatsApp的消息发送、通话等核心功能，并不是完全依赖HTTP/HTTPS：

• 它主要用WebSocket传输实时消息（mitmproxy支持WebSocket拦截，但需要确保配置正确）；
• 语音/视频通话和部分消息会用自定义UDP协议（WhatsApp自己封装的传输层），而mitmproxy默认只处理HTTP/HTTPS流量，对这类自定义UDP协议无能为力。

至于Kik和Snapchat，它们的静态资源（头像、首页加载内容）可能走HTTP/HTTPS，所以你能抓到部分请求，但核心消息发送用了专属协议或者直连，自然抓不到。

3. 证书钉扎（Certificate Pinning）导致静默 fallback #

虽然你说WhatsApp功能正常，但也有可能是证书钉扎在起作用：APP会内置信任的服务器证书哈希值，只有当代理返回的证书（mitmproxy的根证书）和这个哈希匹配时，才会继续使用代理；如果不匹配，APP不会弹出错误，而是悄悄切换回直连模式，保证用户功能正常。这种情况下，你看起来APP能用，但流量根本没经过代理。

• 用Wireshark抓UDP流量：把iPhone和电脑连到同一个WiFi，用Wireshark抓WiFi接口的包，过滤udp协议，看看是否有大量来自WhatsApp官方IP段的流量。如果有，就说明核心数据走UDP，mitmproxy默认抓不到。
• 用VPN级工具强制路由：试试Surge、Shadowrocket这类工具，配置规则让WhatsApp的所有流量强制走mitmproxy。这类工具能绕过APP的代理忽略逻辑，强制把流量导去代理，验证是不是APP刻意绕开了系统代理。
• 测试证书钉扎（需越狱）：如果你的iPhone能越狱，可以用TrustMeAlready这类插件禁用WhatsApp的证书钉扎，再用mitmproxy抓包。如果这时能抓到流量，就说明是证书钉扎导致的代理失败。

内容的提问来源于stack exchange，提问作者james738