UrlEdge
回到博客
2026年5月17日 UrlEdge Editorial3 min read

在 edge 提供验证文件:ads.txt、security.txt、AASA 与 assetlinks.json

有些文件必须放在 root 或 /.well-known/。如果 CMS 或站点平台不方便,edge response 可以直接用正确的 status 和 Content-Type 提供它们。

root 和 .well-known 验证文件由 edge response layer 直接提供

验证文件真正麻烦的地方通常不是内容,而是 path。

ad ops 需要 root 下的 ads.txt。security 需要 /.well-known/security.txt。mobile 需要 apple-app-site-association。Android 需要 assetlinks.json。CMS、storefront 或 site builder 也许对普通页面没问题,但在这些特定 URL 上就容易出问题。

于是一个小文件就能挡住广告验证、security disclosure、app link 或 migration。

如果你也在处理 Universal Links 或 Android App Links,可以一起看 Firebase 后如何配置 Universal Links 和 App Links。这篇只讲文件的提供方式。

root 和 .well-known 的问题

这些文件很小,但验证它们的平台通常很严格。

常见错误:

  • CMS 不允许 root file
  • /.well-known/ 被 app router 捕获
  • 文件前面多了一层 redirect
  • Content-Type 不对
  • launch 之后没人负责更新

edge 的价值在于,它可以在目标 path 上直接响应,而不必把整个站点变成基础设施工程。

Edge response map for root and .well-known verification files

每个文件都有不同职责

ads.txtapp-ads.txt

它们用于广告透明度和授权 inventory。最重要的是易于抓取:

  • 直接 path
  • 200 response
  • plain text
  • owner 明确

如果放在 login、redirect 或 CMS fallback 后面,验证可能失败。

security.txt

security.txt 用来告诉外界如何报告漏洞。很多团队会在 web、security、legal、platform 之间反复推诿。

edge response 能让 path、body、Content-Type、owner 都变得清楚。

apple-app-site-association

Apple Universal Links 依赖 AASA 文件在正确的位置。文件一旦出错,团队往往会先去 debug app,而不是文件 delivery。

assetlinks.json

Android App Links 依赖有效的 assetlinks.json。如果文件缺失、过期,或者被 site builder 改写,domain verification 就会变得不稳定。

edge response 要做对什么

它不需要聪明,只需要准确。

Verification file requirements for path, status code, content type, and owner

FileTypical pathRequirementCommon mistake
ads.txt/ads.txt200, text, stable content放在 redirect 或 login 后面
app-ads.txt/app-ads.txt200, text, app inventory忘了 app 自己有 inventory
security.txt/.well-known/security.txt or /security.txt200, text, current contactroot path 没有 owner
apple-app-site-association/.well-known/apple-app-site-association or /apple-app-site-association200, JSON, exact bodyContent-Type 或 path 错误
assetlinks.json/.well-known/assetlinks.json200, JSON, exact body被 CMS 改写 route

如果某个平台要求不同的 exact path,就按它的文档来。重点是保持验证契约可读、可检。

不要把这些文件藏在 redirect 后面

对于验证文件,直接返回通常更稳。

多一跳就多一个故障点。排查也会变难,因为昨天还通过、今天却失败的情况很常见。

只有当 consumer 明确接受 redirect 时才这么做。否则应直接提供。

先定 ownership

这些文件会在 launch 后被遗忘,所以很容易出问题。

一个实用分工:

  • ad ops 负责 ads.txtapp-ads.txt
  • mobile engineering 负责 AASA 和 assetlinks.json
  • security 或 platform 负责 security.txt
  • web/platform 负责 path、status、Content-Type

在 CMS 迁移、rebrand 或 app 调整时,这种 ownership 能省很多时间。

一套可执行的流程

  1. 为每个文件确定 exact path
  2. 定义 body 和 Content-Type
  3. 直接从 edge 提供
  4. 记录 owner 和 review date
  5. 用真实 consumer 测试,而不是只在浏览器里看

如果你不想为了几个 root file 就增加 origin deploy,这种方式很合适。

UrlEdge 适合放在哪

UrlEdge 的 Custom Response Tool 可以直接从 edge 提供短文本或 JSON response。

适用于:

  • origin 不擅长处理 root 或 .well-known
  • 需要直接 200
  • 需要控制 Content-Type 和 body
  • domain 本来就已经在 UrlEdge 上做 redirects 或 routing

它不是 deep link stack 的全部替代品,只是移除文件托管的摩擦。

FAQ

这些文件必须放在 origin 上吗?

不需要。它们只需要在预期 path 上可以正确读取。如果 origin 做不到,edge delivery 是现实方案。

可以 redirect 它们吗?

只有当验证平台明确接受时才行。通常直接 response 更稳。

为什么不交给 CMS?

很多 CMS 对页面很强,但对 root 或 /.well-known/ 很弱。这里正是要补的空缺。

这只是 mobile app 的问题吗?

不是。AASA 和 assetlinks.json 属于 app,但 ads.txtapp-ads.txtsecurity.txt 属于广告与安全。

参考

不改 origin 也能提供验证文件

把 root 和 .well-known 文件放到 edge,保持 status、Content-Type 和 ownership 清晰。

查看 edge responses

相关文章

查看全部