Firebase动态链接关闭预览页经内部跳转后无法在iOS端打开应用

可能原因分析 #

• iOS Universal Link 重定向链路限制：iOS 14及以上系统对Universal Link的触发规则有严格限制，若跳转链路中存在超过1次的非用户主动触发的服务器端3xx重定向，系统会自动终止Universal Link识别逻辑，无法拉起对应应用，直接跳转至目标链接的Safari页面。新增的内部重定向层刚好在用户点击源链接到Firebase动态链接之间多了一次重定向，符合这个触发条件。
• Firebase动态链接来源校验：关闭预览页模式（即添加efr=1参数）下，Firebase会对请求的来源上下文做校验，如果识别到请求来自中间重定向服务而非用户直接点击，会判定为非合规流量，不返回触发Universal Link的响应头，转而走网页跳转逻辑。
• 重定向配置不符合iOS交互规则：如果内部重定向服务使用前端JS跳转（返回200状态码后通过window.location跳转）而非标准3xx服务器端重定向，iOS会判定为非用户主动触发的跳转，拦截Universal Link唤起流程。
• 重定向响应头配置缺失：除了User-Agent外，可能缺失了Referrer-Policy相关配置，导致跳转至Firebase时没有携带正确的来源信息，Firebase无法验证请求合法性，拒绝触发直接拉起逻辑。

排查思路 #

• 先确认重定向服务的跳转方式：优先使用302临时重定向，不要用301永久重定向（会被系统缓存导致后续测试结果不准），禁止使用前端JS跳转实现重定向逻辑。
• 调整重定向链路测试：可以先在内部重定向服务配置直接返回Firebase动态链接的302响应，不带任何额外业务参数，排查是否是业务参数拼接错误导致的问题。
• 校验Firebase动态链接参数：确认手动拼接的关闭预览页参数efr=1配置正确，同时检查ibi（iOS bundle ID）、isu（iOS自定义Scheme）等iOS专属参数是否和直接访问时的参数完全一致。
• 抓取iOS端请求日志：用Charles或Safari开发者工具抓取从点击源链接到跳转结束的全链路请求，对比加中间层和不加中间层两种场景下，请求Firebase动态链接时的请求头、响应头差异，重点看Referer、User-Agent、响应头里的Location以及Universal Link相关的apple-app-site-association相关返回。
• 测试降级跳转逻辑：如果无法解决重定向链路的Universal Link识别问题，可以考虑在内部重定向层对iOS流量做特殊处理，直接返回自定义Scheme跳转+App Store兜底的逻辑，绕过Firebase的直接拉起校验。

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