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

验证文件真正麻烦的地方通常不是内容,而是 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 上直接响应,而不必把整个站点变成基础设施工程。

每个文件都有不同职责
ads.txt 和 app-ads.txt
它们用于广告透明度和授权 inventory。最重要的是易于抓取:
- 直接 path
200response- 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 要做对什么
它不需要聪明,只需要准确。

| File | Typical path | Requirement | Common mistake |
|---|---|---|---|
ads.txt | /ads.txt | 200, text, stable content | 放在 redirect 或 login 后面 |
app-ads.txt | /app-ads.txt | 200, text, app inventory | 忘了 app 自己有 inventory |
security.txt | /.well-known/security.txt or /security.txt | 200, text, current contact | root path 没有 owner |
apple-app-site-association | /.well-known/apple-app-site-association or /apple-app-site-association | 200, JSON, exact body | Content-Type 或 path 错误 |
assetlinks.json | /.well-known/assetlinks.json | 200, JSON, exact body | 被 CMS 改写 route |
如果某个平台要求不同的 exact path,就按它的文档来。重点是保持验证契约可读、可检。
不要把这些文件藏在 redirect 后面
对于验证文件,直接返回通常更稳。
多一跳就多一个故障点。排查也会变难,因为昨天还通过、今天却失败的情况很常见。
只有当 consumer 明确接受 redirect 时才这么做。否则应直接提供。
先定 ownership
这些文件会在 launch 后被遗忘,所以很容易出问题。
一个实用分工:
- ad ops 负责
ads.txt和app-ads.txt - mobile engineering 负责 AASA 和
assetlinks.json - security 或 platform 负责
security.txt - web/platform 负责 path、status、Content-Type
在 CMS 迁移、rebrand 或 app 调整时,这种 ownership 能省很多时间。
一套可执行的流程
- 为每个文件确定 exact path
- 定义 body 和 Content-Type
- 直接从 edge 提供
- 记录 owner 和 review date
- 用真实 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.txt、app-ads.txt 和 security.txt 属于广告与安全。
参考
不改 origin 也能提供验证文件
把 root 和 .well-known 文件放到 edge,保持 status、Content-Type 和 ownership 清晰。
查看 edge responses相关文章
查看全部
www、apex 与 wildcard forwarding:怎样不破坏 SEO
host normalization 看起来简单,但当 root、www、subdomain、path 和 query string 各自有不同规则时,redirect chain 很快就会出现。先定 canonical host 才是关键。

付费与联盟流量的链接防火墙:在入口过滤 bot、代理和坏点击
并不是每个坏点击都是作弊,但每个坏点击都会影响预算、归因和合作方报表。链接防火墙是在流量到达目标页之前决定它该怎么处理。