苹果iCloud专用代理Passkey漏洞会泄露真实IP原理
iCloud专用代理（Private Relay）配合Passkey登录时，存在一种可能泄露真实IP的链路：当认证请求绕过代理直连原始服务器时，服务端记录到的IP就不是苹果代理节点，而是你的真实出口地址。
下面从原理、边界和自查三个层面展开。
iCloud专用代理与Passkey的性质差异
iCloud专用代理是Safari浏览器内建的流量转发服务，将网页请求分成两跳：第一跳拿到你的匿名IP，第二跳以苹果出口IP访问目标站点。
Passkey则是基于WebAuthn的无密码认证，登录时要向网站域名发出认证挑战。
问题不出在Passkey本身，而在于WebAuthn流程中的某些请求不一定走专用代理。
IP泄露的关键环节
Passkey认证通常依赖关联域（Associated Domains）和苹果的服务器做密钥同步。
在iCloud钥匙串同步Passkey时，设备会访问 icloud.com 等苹果域名，也可能触发直接连接。
如果专用代理对部分域名的流量不生效，或者Safari内请求被API调用代替，那么目标服务器或苹果同步节点就能看到你的真实IP。
另一个容易被忽视的路径是：Passkey使用中若触发“已验证域名”检查，会向开发者域名发起 .well-known/apple-app-site-association 请求。
这类请求在部分网络环境下会绕过代理，导致真实IP暴露给该网站运维方。
哪些场景风险更高
- 使用自定义域名做Passkey的网站，且该域名不在专用代理的白名单行为覆盖下。
- 关闭了“限制IP地址跟踪”开关时，专用代理失效。
- 非Safari浏览器调用Passkey或使用原生App内WebView时，专用代理完全不介入。
- 企业证书或描述文件强制网络代理时，Passkey同步链路可能回退直连。
自查与验证思路
先确认当前是否走代理：在Safari里访问IP检测网站，记录显示IP；
再用同一设备关闭iCloud专用代理后对比。
若IP一致，说明代理已失效或未覆盖。
进一步验证：用另一台未登录iCloud的设备访问同一网站，对比服务端日志或在线检测结果。
若两端IP相同且接近真实宽带归属地，基本可以确认链路中有绕过。
不要用微信或App内置浏览器测试，因为它们不接入专用代理。
测试时建议切换Wi-Fi与蜂窝网络各一次，排除运营商NAT干扰。
现阶段防护建议
在苹果官方文档确认修复前，可以这样做：
- 登录与钱包无关的普通网站时，优先使用Safari并要求专用代理对当前网站生效。
- 对隐私要求高的网站，关闭Passkey自动填充，改用一次性密码或独立密码管理器。
- 在系统设置中确认“限制IP地址跟踪”处于开启状态。
- 需要更强隐私时，叠加合规VPN，确保所有流量都经过隧道。
- 关注iOS安全更新，该问题通常以系统更新或域名列表调整方式修复。
结论是：该漏洞的实质是Passkey的认证链路穿透了iCloud专用代理，而不是专用代理失效；
普通用户不必停用Passkey，但对高隐私场景应保留手动开关，并用IP检测手段定期核验实际出口地址。
