iOS端Edge浏览器SafeLink问题：跳转App Store而非目标应用

问题概述 #

启用SafeLink政策后，未包装的原始URL可在所有浏览器正常触发深度链接，但经SafeLink包装后的URL仅能在Safari中生效，其他浏览器无法触发深度链接功能。

核心原因分析 #

• 浏览器重定向处理逻辑差异：Chrome、Edge等浏览器对跨域重定向的深度链接触发有严格限制。SafeLink通过微软保护域名（如nam12.safelinks.protection.outlook.com）做302重定向，这类第三方域名的跳转可能被浏览器判定为非直接访问，从而跳过深度链接触发逻辑；而Safari对重定向后的URL深度链接触发兼容性更强，允许跨域重定向后触发。
• URL编码异常：示例中的SafeLink目标URL存在格式问题（如<SITELINK (Eg.xxx.yyy.com)>后多余的点），若实际环境中存在编码错误，会导致解码后的目标URL无效，部分浏览器容错性差无法解析，而Safari可能自动修正这类小错误。
• 应用深度链接配置限制：部分应用的Universal Links（iOS）或Intent Filter（Android）仅配置了直接匹配目标域名的规则，未考虑经过SafeLink重定向的场景，导致重定向后的URL无法匹配应用的深度链接规则。

解决方案建议 #

• 校验SafeLink目标URL编码：使用URL解码工具解析SafeLink中的url参数，确认解码后的URL与原始非SafeLink URL完全一致，排查是否存在编码错误、多余字符或格式问题。
• 调整浏览器与应用的白名单配置：
  • 对于Chrome/Edge，将SafeLink域名添加到应用深度链接的允许列表中；
  • 更新iOS应用的apple-app-site-association文件，允许从SafeLink域名的重定向触发Universal Links；
  • 调整Android应用的Intent Filter，增加对SafeLink重定向场景的支持。
• 优化SafeLink政策配置：若组织有权限修改Exchange/Office 365的SafeLink设置，启用“直接重定向”选项，减少中间页面的跳转环节，让浏览器直接处理目标URL的深度链接触发。
• 测试并调整深度链接触发逻辑：在应用端测试经过重定向的URL是否能触发深度链接，若无法触发，修改应用的深度链接匹配规则，支持重定向后的URL路径参数。
• 临时替代方案：在邮件中同时提供SafeLink和原始URL（标注安全提示），或使用组织内部的短链接服务替代SafeLink，确保所有浏览器都能正常触发深度链接。

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