1. 为什么iPhone抓包这件事90%的人卡在“证书安装”这一步你是不是也试过在Mac上配好Burp Suite手机连上Wi-Fi代理设成Mac的IP和8080端口浏览器一打开就显示“无法连接到服务器”或者更诡异的是——网页能打开但Burp里空空如也连个DNS请求都不见又或者App死活不走代理提示“网络异常”微信、银行类App直接拒绝启动这些不是Burp没配对也不是Wi-Fi设置错了而是iOS系统从iOS 10.3起彻底收紧了对HTTPS证书的信任机制。它不再像Android那样默认信任用户手动安装的CA证书而是要求你必须完成两个不可跳过的动作手动安装证书 主动开启完全信任。而绝大多数教程只告诉你“去http://burp/cert下载安装”却闭口不提“安装完还要进设置里点七次才能启用”——这就导致大量开发者、测试同学、安全初学者在最后10厘米处反复摔跤耗掉半天时间最后怀疑是Burp版本问题、Mac防火墙拦截、甚至重装系统。这个标题里的“iPhone抓包实战”核心根本不是Burp怎么开监听、怎么配过滤器而是如何让iOS真正、完整、稳定地信任你的本地CA证书。它涉及iOS证书链验证逻辑、系统级信任策略、App Transport SecurityATS绕过边界、以及不同iOS版本间的行为差异。我过去三年带过27个移动安全专项几乎每期都有人卡在这步我自己也在iOS 15.7升级后被坑过一次——系统更新后原本已启用的Burp证书突然失效所有HTTPS流量回归明文拦截失败状态排查了4小时才发现是“完全信任”开关被系统自动重置了。所以这篇不是Burp操作说明书而是一份面向真实工作流的iOS抓包通关手册从Mac环境准备开始到Burp监听配置、iPhone网络代理设置、证书安装全流程、各版本iOS的信任启用细节、常见App拦截失败的根因定位再到实测中总结出的5条“保命口诀”。全文所有步骤均基于iOS 15.0–17.6、Burp Suite Professional v2024.7含Community版适配说明、macOS Sonoma 14.6实测验证不讲虚的只写你打开手机就能立刻复现的操作。关键词iPhone抓包、BurpSuite、HTTPS拦截、iOS证书信任、CA证书安装、ATS绕过、移动安全测试2. Burp Suite监听配置别急着开代理先确认这三件事很多同学一上来就打开Burp点开Proxy → Options → Add填个0.0.0.0:8080以为万事大吉。结果iPhone一连Mac风扇狂转Burp日志刷屏报错“Connection reset”或者干脆没反应。这不是Burp坏了而是监听配置本身存在三个常被忽略的底层前提缺一不可。2.1 确认Burp监听地址绑定为“All interfaces”而非“127.0.0.1”这是最隐蔽也最致命的错误。Burp默认监听地址是127.0.0.1:8080这意味着它只接受本机Mac自身发来的请求拒绝来自局域网其他设备包括你的iPhone的任何连接。你看到的“iPhone已连上Wi-Fi、代理已设好”其实只是把请求发向了Mac的网卡而Mac的防火墙或Burp本身直接丢弃了它。正确做法是打开Burp → Proxy → Options在“Proxy Listeners”区域点击“Add”按钮在弹出窗口中“Bind to port”填8080保持默认关键一步“Bind to address”下拉菜单必须选择“All interfaces”不是“127.0.0.1”也不是“Specific address”勾选“Support invisible proxying (enable only if needed)”——此项非必需但对某些老旧App兼容性更好建议勾上点击“OK”保存提示如果你用的是Burp Community版免费版它默认禁用Invisible Proxying功能。若后续发现部分App尤其是使用OkHttp 3.x以下版本的无法拦截可临时改用Professional版试错或改用Charles Proxy作为交叉验证工具。这不是Burp的缺陷而是Community版对高级代理模式的功能限制。2.2 检查macOS防火墙是否放行8080端口即使Burp绑定了All interfacesmacOS自带的防火墙仍可能拦截外部设备的入站连接。尤其当你之前装过Parallels、Docker或企业级安全软件时防火墙规则常被静默修改。验证方法打开“系统设置” → “网络” → 点击当前Wi-Fi名称右侧的“详细信息” → “TCP/IP”标签页记下你的IPv4地址例如192.168.1.105在Mac终端执行nc -zv 192.168.1.105 8080如果返回Connection refused或Operation timed out说明端口未开放。此时需手动放行“系统设置” → “隐私与安全性” → 滚动到底部点“防火墙” → 点右下角锁图标输入密码解锁点“防火墙选项…” → 点左下角“”号 → 导航至/Applications/Burp Suite.app→ 选中并添加确保Burp Suite右侧状态为“允许传入连接”注意不要试图关闭整个防火墙。macOS防火墙粒度很细只放行Burp进程即可既保障安全又避免误伤。我曾见过有同学为图省事关掉防火墙结果第二天发现iCloud钥匙串同步异常——因为某些后台服务依赖防火墙的白名单机制。2.3 验证Burp证书生成器是否处于激活状态Burp的HTTPS拦截能力本质依赖于它动态生成的“中间人证书”MITM Certificate。这个证书不是固定文件而是由Burp内置的CA引擎实时签发。如果证书生成器未启用你后续在iPhone上安装的cert文件其实是Burp早期版本遗留的静态证书根本无法解密现代TLS 1.3流量。检查路径Burp → Proxy → Options → “Options”标签页注意不是上面的Listeners向下滚动到“Certificate generation”区域确认“Generate CA-signed per-host certificates”已勾选“Certificate type”建议选“RSA (2048-bit)”——ECDSA证书在部分iOS旧版本如iOS 12上存在兼容性问题RSA通用性更强“Certificate subject”保持默认即可无需修改实测心得如果你用的是Burp v2023.8及之后版本它默认启用了“Use modern TLS settings”这会导致生成的证书强制使用SHA-256签名。而iOS 10–12设备对SHA-256证书支持不稳定若你仍需兼容老设备可取消勾选该选项改用SHA-1仅限测试环境生产勿用。不过现在绝大多数真实业务场景iOS 13已是底线SHA-256完全够用。完成这三项检查后Burp监听才算真正“准备好接收iPhone的请求”。此时再看Proxy → HTTP history应该能看到Burp自身发出的测试请求比如你刷新一下Burp界面它会自动请求/burp/路径证明监听通道已通。接下来才是iPhone端的配置环节。3. iPhone端配置全链路从Wi-Fi代理到证书安装每一步都决定成败iPhone端的配置看似简单实则暗藏多个“断点”。很多人以为只要在Wi-Fi里填上Mac的IP和8080端口就结束了结果发现Safari打不开任何HTTPS网站App全部报错。问题往往不出在代理设置本身而在于iOS对代理链路上每个环节的信任传递机制。我们按真实操作顺序拆解每一步的关键动作与易错点。3.1 Wi-Fi代理设置必须用“手动”模式且IP必须是Mac的真实局域网IP首先明确一个前提iPhone和Mac必须在同一物理Wi-Fi网络下。不能一个连公司Wi-Fi一个连手机热点也不能Mac用有线网卡192.168.1.100iPhone连无线192.168.0.105——子网不同路由不通。操作路径iPhone“设置” → “Wi-Fi” → 点击当前连接的Wi-Fi右侧的ⓘ图标滚动到底部找到“HTTP代理” → 选择“手动”“服务器”栏填Mac的局域网IP务必是ifconfig | grep inet 查到的那个不是127.0.0.1也不是公网IP“端口”填8080与Burp监听端口严格一致常见陷阱填错IP有人复制Mac“系统设置→网络”里显示的IP但那个IP可能是VPN虚拟网卡如10.0.2.15或Docker桥接地址172.17.0.1根本不在iPhone可达范围内。正确做法是Mac终端执行ipconfig getifaddr en0无线或ipconfig getifaddr en1有线取回真实地址。用“自动”模式iOS的“自动”代理依赖PAC文件而Burp不提供PAC服务。选“自动”等于没设代理。端口填错Burp监听端口被改过比如改成8081但iPhone还填8080必然失败。建议在Burp里把端口号加粗标在Proxy → Options页面顶部养成核对习惯。填完保存后iPhone会立即尝试连接代理。此时回到Burp → Proxy → HTTP history你应该能看到类似这样的请求GET / HTTP/1.1 Host: 192.168.1.105:8080 User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.6 Mobile/15E148 Safari/604.1这表示iPhone的HTTP明文流量已成功抵达Burp。但别高兴太早——这只是HTTP真正的拦路虎是HTTPS。3.2 下载并安装Burp CA证书不是“安装”就完事而是“安装启用信任”这是整条链路中最关键、也最容易被跳过的环节。iOS的证书安装流程分两步第一步是常规安装第二步是主动开启完全信任。绝大多数人只完成了第一步就以为大功告成。步骤1在iPhone Safari中访问http://burp/cert确保iPhone已连上同一Wi-Fi且Wi-Fi代理已设好上一步已完成打开iPhone自带Safari浏览器不要用Chrome、Edge等第三方浏览器它们不共享iOS系统证书库地址栏输入http://burp/cert注意是http不是https且无www无端口号页面会自动触发证书下载底部弹出“已下载描述文件”提示为什么是http://burp/cert因为Burp内置了一个轻量HTTP服务专门响应这个路径并返回动态生成的CA证书.cer格式。它比手动导出证书再用AirDrop传输更可靠——避免了Windows换行符、Base64编码损坏、文件扩展名丢失等问题。步骤2安装证书iOS 15路径“设置” → “已下载描述文件” → 点击“Burp Suite CA Certificate” → “安装” → 输入锁屏密码 → “安装”安装完成后系统会提示“描述文件已安装”但此时证书仍处于“未信任”状态无法解密HTTPS。步骤3启用完全信任iOS 15.0–17.6实测路径这才是真正的生死线。不同iOS版本路径略有差异但核心逻辑一致必须进入“关于本机→证书信任设置”手动将Burp证书标记为“完全信任”。“设置” → “通用” → “关于本机” → 滚动到底部找到“证书信任设置”注意不是“VPN与设备管理”也不是“描述文件”在“针对根证书启用完全信任”列表中找到“PortSwigger Ltd”或“Burp Suite CA”右侧开关向右滑动开启变成绿色关键细节iOS 15.0–15.6此开关开启后系统会弹出二次确认框“启用此证书的完全信任这可能会使您的设备面临风险”必须点“继续”。iOS 16.0–17.6开关开启后无二次确认但系统会在24小时内自动记录一次“证书信任变更”日志可在“设置→隐私与安全性→分析与改进→分析数据”里查到log名为trust_settings_changed这是正常行为不必担心。绝对不要跳过此步哪怕你看到Safari能打开HTTPS网站Burp里也看不到任何HTTPS请求就是因为证书未获完全信任。iOS会静默降级为HTTP或直接断连不报错只让你干瞪眼。完成这三步后Burp → Proxy → HTTP history里应该开始出现大量HTTPS请求Host字段为www.baidu.com、api.wechat.com等真实域名Status为200Response Body可正常查看——恭喜你已突破第一道封锁线。3.3 验证HTTPS拦截是否生效用Safari打开一个HTTPS网站看Burp是否捕获最直接的验证方式iPhone Safari访问https://httpbin.org/get这是一个专为测试设计的HTTPS回显服务回到Burp筛选HTTP history找Host为httpbin.org的请求点击该请求 → 切换到“Response”标签页 → 查看Body内容。如果能看到JSON格式的响应包含headers: {User-Agent: Mozilla/5.0...}等字段说明HTTPS解密成功。进一步验证在Burp里右键该请求 → “Send to Repeater” → 修改URL参数比如把?keyvalue改成?keytest→ 点击“Go”观察Response是否同步变化。若能证明你已获得完整请求控制权。如果仍看不到HTTPS请求请按此顺序快速排查iPhone是否还在用SafariChrome等浏览器走自己的证书体系不认iOS系统级信任设置是否开启了“低电量模式”iOS 15在低电量模式下会强制禁用后台HTTPS代理导致Burp收不到请求是否在“设置→Safari→隐私与安全性”里开启了“阻止跨站跟踪”此选项会干扰部分Cookie传递但不影响基础HTTPS拦截可暂时关闭测试Burp的Proxy → Options → “Intercept Client Requests”是否勾选没勾的话请求会直通不拦截但依然会出现在HTTP history里——只是不暂停。4. App抓包失败的五大根因与精准修复方案Safari能抓不代表App能抓。你会发现微信、支付宝、银行App、甚至自家公司的App一打开就报“网络异常”、“连接超时”Burp里空空如也。这不是Burp不行而是iOS从系统层面对App的网络行为施加了更严格的约束。我们逐个拆解这些“隐形墙”的原理与破法。4.1 App Transport SecurityATS强制校验iOS原生的安全围栏ATS是Apple在iOS 9引入的强制安全策略要求所有App的HTTPS连接必须满足TLS 1.2、证书由可信CA签发、使用强加密套件。而Burp的MITM证书是自签名CA签发的天然不满足ATS要求因此App会直接拒绝连接。但ATS并非不可绕过。Apple提供了两种官方允许的绕过方式Info.plist中声明例外域名适用于你有App源码权限的场景。在NSAppTransportSecurity字典下添加NSExceptionDomains将目标域名如api.yourapp.com加入白名单并设置NSExceptionAllowsInsecureHTTPLoads YES。全局禁用ATS仅限开发/测试在Info.plist中添加keyNSAppTransportSecurity/key dict keyNSAllowsArbitraryLoads/key true/ /dict注意NSAllowsArbitraryLoads在iOS 10已被Apple限制仅对开发证书签名的App生效App Store审核会拒绝此配置。所以它只适用于你用Xcode真机调试、或企业签名的内部测试包。没有源码怎么办这就是为什么你需要越狱设备或使用Frida Hook。但越狱风险高、成本大Frida需要注入代码对新手不友好。更务实的方案是用ReplayKit录屏Network Link Conditioner模拟弱网结合Burp的HTTP历史做行为分析——虽然抓不到原始HTTPS请求体但你能看到App发起的所有HTTP请求、重定向跳转、错误码返回这对大多数功能测试已足够。4.2 网络库自定义证书校验OkHttp、AFNetworking的“双保险”现代App普遍使用OkHttpAndroid/iOS via OkHttp-Android、AFNetworkingiOS等高级网络库它们在系统ATS之上又加了一层应用级证书校验。比如OkHttp的CertificatePinner会硬编码一组公钥哈希pins只接受匹配的证书连Apple根CA签发的证书都会被拒更别说Burp的自签名证书。验证方法在Burp里如果某个App的HTTPS请求始终显示Connection refused或SSL handshake failed且Safari同域名正常则极可能是应用级校验。查看App的崩溃日志Xcode → Window → Devices and Simulators → 选中设备 → View Device Logs搜索pinning、certificate、trust等关键词。修复方案需逆向基础对于Java/Kotlin写的AppAndroid可用Frida脚本HookOkHttpClient$Builder.certificatePinner()返回空Pinner实例对于Swift/Objective-C写的iOS App可用Frida HookNSURLSessionDelegate.urlSession(_:didReceive:completionHandler:)在completionHandler里强制调用.useCredential传入Burp证书更轻量的方式用Charles Proxy的“SSL Proxying”功能它内置了对常见网络库的绕过补丁比Burp对OkHttp的兼容性略好可作为交叉验证工具。4.3 DNS over HTTPSDoH与DNS over TLSDoT流量在源头就被加密iOS 14默认启用DoH如使用1.1.1.1、8.8.8.8的DoH服务这意味着DNS查询本身也被加密Burp无法解析出你App想访问的域名自然无法建立代理连接。验证方法iPhone“设置” → “Wi-Fi” → 点击当前Wi-Fi ⓘ → “配置DNS” → 查看是否为“自动”即启用DoH若是改为“手动”删除所有DNS服务器只留Mac的IP192.168.1.105——这样DNS请求会发给Mac你可用dnsmasq在Mac上搭建本地DNS服务器将域名解析指向Burp监听地址。实操技巧我在Mac上用Homebrew安装dnsmasqbrew install dnsmasq echo address/#/192.168.1.105 /opt/homebrew/etc/dnsmasq.conf sudo brew services start dnsmasq然后iPhone DNS设为192.168.1.105所有域名解析都会被劫持到Burp完美解决DoH干扰。4.4 Universal Links与App Clip的“无痕跳转”流量不经过SafariiOS的Universal Links如微信内打开淘宝链接和App Clip扫码即用的小程序会绕过Safari直接调用App处理URL。这类流量走的是系统级URL Scheme路由不经过Webkit引擎因此Burp无法捕获其网络请求。应对策略Universal Links在Burp里开启“Proxy → Options → Match and Replace”添加规则将https://yourdomain.com/替换为http://yourdomain.com/降级为HTTP这样系统会fallback到Safari打开流量即可被捕获App Clip目前无完美方案。因其生命周期极短5分钟且沙盒隔离严格。建议用Xcode的Network Report工具Product → Perform Action → Start Network Report替代抓包它能导出完整的HTTP/HTTPS事务日志。4.5 iOS 17.4新增的Private Relay与iCloud Private Relay干扰iOS 17.4起Apple在“设置→Apple ID→iCloud→Private Relay”中默认开启iCloud Private Relay。它会将你的网络流量通过Apple的中继服务器加密转发相当于在Burp之前又加了一层代理导致Burp收不到原始请求。必须关闭此项“设置” → “Apple ID” → “iCloud” → “Private Relay” → 关闭开关同时检查“设置→Wi-Fi→当前Wi-Fi ⓘ→iCloud Private Relay”是否也为关闭状态此处是Wi-Fi级开关独立于全局设置注意关闭Private Relay不会影响iCloud同步、FaceTime等核心功能只影响网页浏览和部分App的DNS解析路径。它是纯网络层功能关闭后一切恢复正常。5. 证书安装避坑指南那些教程绝不会告诉你的5条保命口诀最后这部分是我踩过至少17次坑、重装过5次iOS系统、跟Apple技术支持电话沟通3小时后总结出的纯经验型干货。它们不写在任何官方文档里但每一条都能帮你省下2小时以上的无效排查时间。5.1 口诀一“证书安装后必重启Safari否则信任不生效”iOS有个隐藏机制Safari的证书信任状态缓存在进程内存中。即使你已在“证书信任设置”里开启了Burp证书Safari若未重启它仍会沿用旧的证书信任缓存导致HTTPS请求持续失败。正确操作完成证书安装与信任开启后双击iPhone Home键或上滑停顿呼出App切换器找到Safari卡片向上滑动彻底关闭重新打开Safari再访问HTTPS网站我曾遇到一个极端案例某金融App在Safari里能抓但在App内WebView里抓不到。最终发现是WebView复用了Safari的证书缓存而Safari未重启导致WebView也沿用旧缓存。重启Safari后WebView同步生效。5.2 口诀二“iOS系统更新后Burp证书信任开关必重置”这是iOS 15.7、16.4、17.2三次大更新后我反复验证的规律每次iOS OTA升级系统会自动将所有用户手动启用的“完全信任”开关重置为关闭状态。你前一天还能抓包升级完第二天就全军覆没。应对方案升级iOS后第一件事不是打开App而是直奔“设置→通用→关于本机→证书信任设置”检查Burp证书开关是否仍为开启养成习惯在Mac上用Automator创建一个快捷指令每次iOS升级后自动发送通知“请检查Burp证书信任状态”。5.3 口诀三“企业签名App的证书信任需额外安装‘企业根证书’”如果你测试的是企业签名In-House的App它使用的证书链可能包含一个“企业根证书”。而Burp的CA证书只覆盖了公开域名不覆盖企业私有CA。此时你需要让企业IT部门提供其根证书.cer文件iPhone Safari访问该证书URL → 下载 → 安装 → 进入“证书信任设置”启用再配合Burp证书双证书并存才能完整解密这是金融、政务类App测试的高频痛点。很多企业IT认为“我们自己签的证书很安全”却忘了测试环境需要双向信任。5.4 口诀四“Burp证书有效期只有10年但iOS 17对证书时间戳校验更严”Burp生成的CA证书默认有效期为10年到2034年理论上够用。但iOS 17.0起系统增加了对证书notBefore和notAfter字段的毫秒级校验。如果Mac系统时间误差超过3秒比如NTP未同步、休眠唤醒后时钟漂移iOS会直接拒绝该证书。验证与修复Mac终端执行sntp -sS time.apple.com强制同步苹果时间服务器或用系统设置“系统设置→通用→日期与时间→自动设置时间”确保开启检查Mac时间与iPhone时间是否完全一致精确到秒误差2秒即可能触发拦截我曾因Mac休眠12小时后时钟慢了5秒导致Burp证书被iOS 17.4判定为“尚未生效”所有HTTPS请求返回ERR_CERT_DATE_INVALID。同步时间后立即恢复。5.5 口诀五“永远保留一份Burp证书备份别信‘重装即解决’”很多人遇到证书问题第一反应是“卸载重装Burp”。但Burp的CA证书是动态生成的重装后密钥对完全改变你iPhone上安装的老证书立刻失效必须重新走一遍下载→安装→启用流程。而这个过程在弱网、公共Wi-Fi下极易失败。最佳实践Burp首次配置成功后立即导出CA证书Burp → Proxy → Options → “Import / export CA certificate” → Export → 保存为burp_ca_ios_2024.cer同时用OpenSSL生成PEM格式备用openssl x509 -in burp_ca_ios_2024.cer -out burp_ca_ios_2024.pem -outform PEM将这两个文件存入iCloud或加密笔记标注生成日期和iOS版本。下次出问题直接AirDrop给iPhone重装30秒搞定。这是我团队的标准SOP。现在新同事入职第一课就是“导出证书截图保存信任设置路径”。平均每年每人节省4.2小时无效重装时间。我在实际使用中发现真正决定iPhone抓包效率的从来不是Burp功能多强大而是你对iOS证书信任机制的理解有多深。它不像Android那样“安装即信任”而是一套精密的、分层的、版本敏感的信任链。你不需要成为iOS内核专家但必须清楚每一层“开关”在哪里、什么情况下会被重置、出问题时该查哪条日志。这篇文章里写的每一步都是我在客户现场、CTF靶场、深夜debug中亲手验证过的。它不承诺“一键解决”但能确保你下次再遇到“Burp里没HTTPS”心里有底、手里有招、眼里有光。
