公共后缀列表与站点边界：10239条规则拆解与45个平台实测

摘要：浏览器判断两个域名算不算同一个站，决定权不在域名注册商，也不在DNS，而在一份放在代码托管平台上、由志愿者审合并请求的纯文本文件。这次把这份文件的10239条规则全量拆开数了一遍，又用真实浏览器实测了45个托管平台的边界判定。最刺眼的一组结果是：在某个知名博客平台的一个租户站上写下的Cookie，换到另一个毫不相干的租户站，16个请求原封不动把它带了过去。更麻烦的一层在浏览器这边：你机器里装的那份清单，实测停在四个月前。

起点是一次常规排查。

一个客户把内容后台迁到了Headless架构上，前端部署在托管平台的二级域下，内容后台在另一个平台的二级域下，中间还有一个给编辑用的预览环境。上线三周，编辑那边反复投诉：预览环境每天要重新登录好几次，而正式站的登录态一直正常。开发查了会话超时、查了负载均衡的粘性、查了时钟偏移，一无所获。

最后定位到的原因只有一句话：预览域所在的那个托管平台，浏览器不认为它的两个客户之间需要隔离，也不认为同一个客户的两个子域属于同一个站——因为这家平台压根没在那份清单上登记过。

清单的名字叫公共后缀列表，英文是Public Suffix List，圈子里习惯叫它PSL。它管的范围比多数人以为的宽：Cookie能写到哪一层、跨站请求算不算跨站、缓存怎么分区、隐私隔离按什么单位切。上一篇拆SameSite在支付回跳时怎么把会话弄丢，讲的是跨过边界之后会发生什么；这一篇往上游走一层，讲边界本身是谁划的。

下面的数字全是这两天现拉现测的：PSL原文的全量统计、45个平台域的逐个核查、真实Chrome与Chromium双版本的跨租户实验，以及一次专门设计的快照比对。有两个结果和保哥事先的判断相反，其中一个直接推翻了原本准备写进去的建议。

eTLD+1如何决定两个域名算不算同一个站？

多数人的默认答案是：域名一样就是一个站，域名不一样就是两个站。这个答案在shop.example.com和www.example.com身上碰巧成立，换个场景立刻就错。

浏览器用的定义是另一套。Google在自家开发者文档里把它写得很直白：一个“站”由协议、有效顶级域，以及紧贴在有效顶级域左边的那一个标签共同构成，这个组合通常写作eTLD+1。

为什么不能靠数点号切分域名

有效顶级域这个词里的“有效”两个字，是全部麻烦的来源。

example.com的顶级域是com，切一刀就够。example.co.uk呢？如果照样只切最后一段，得到的是uk，那么a.co.uk和b.co.uk就成了同一个站的兄弟子域——这意味着任意一家英国公司都能给另一家写Cookie。显然不能这么算。

问题在于，co.uk要当成一个整体、com不用，这件事没有任何算法能从域名字符串本身推出来。它属于注册政策，不属于语法。唯一的办法是查表，这张表就是PSL。

同一条边界同时决定了哪些机制

如果它只管Cookie，重要性还有限。实际情况是，现代浏览器把相当多的机制都挂在了同一个判定上：

别把它当成冷门的规范细节。同一条边界判定被复用在很多处：一处判错，多处跟着错。

公共后缀列表这份文件里到底写了些什么？

我把2026年7月28日这天的PSL原文完整拉了下来，逐行解析。全文332855字节、16410行，去掉注释和空行之后是10239条有效规则。

ICANN段与PRIVATE段的性质差异

文件被两组标记切成泾渭分明的两半：

ICANN段有个反直觉的地方：6949条里有5508条是带点的多段后缀，占79.3%，真正的单标签顶级域只有1441个。“顶级域就是最后一段”这个心智模型，对将近八成的条目都是错的。

例外规则全表只有8条

PSL的语法一共三种：普通规则、以*.开头的通配规则、以!开头的例外规则。前两种数量可观——通配规则有281条（ICANN段16条、PRIVATE段265条）。例外规则少得有点好笑：整份清单只有8条。

这8条的内容很有年代感：一条是!www.ck，剩下7条全是日本的市，川崎、北九州、神户、名古屋、札幌、仙台、横滨。原因是日本的地域型域名规则里，市一级默认被当作公共后缀，唯独这几个大城市自己要用，于是单独开了口子。一份被全球浏览器共同依赖的清单，例外条款里躺着的是七座日本城市的名字，互联网基础设施朴素起来大概就是这个样子。

PRIVATE段的登记量集中在谁手里

PRIVATE段的3290条规则来自602个提交块。分布极其不均：

一家云厂商占了整个PRIVATE段的四分之一，而304个提交块（占50.5%）只登记了一条规则。亚马逊那844条按产品线拆成23个块陆续提交——对象存储一块、托管工作流一块、云端开发环境一块。顺带一提，全表最深的一条规则有7段：*.airflow.cn-north-1.on.amazonwebservices.com.cn，光看这一行就知道是谁写的。

另一个细节：能解析出邮箱的590条提交记录里，本地部分为security的有75个，加上其他安全职能前缀一共81个，占13.7%。提交人把它当安全边界在提交，而清单官方并不这么承诺。这个落差后面还会再出现。

同为Headless CMS，为什么有的登记了PSL、有的没有？

知道了清单长什么样，接下来是最实际的问题：你正在用的那些平台，在不在里面？

我按官方匹配算法写了一个查询器，把45个常见的托管、建站、内容平台域逐个跑了一遍。判据很简单：如果一个租户站的eTLD+1等于平台自己的注册域，说明这个平台没登记，所有客户挤在同一个站里；如果eTLD+1是租户自己那一段，说明登记过了，客户各自独立。

这45个域覆盖的正是独立站建站时会摆上台面的那几类方案：托管型SaaS、自建、纯代码，以及近两年冒出来的一堆前端托管。选型清单上通常只比价格、生态和SEO表现，边界这一栏基本没人填。

按平台类型分档，登记率差多少

45家里23家登记了、22家没有，总体几乎对半开。可一拆开就完全不是对半开的样子：最高的一档是100%，最低的一档是17%，中间几乎没有过渡地带。

我原本准备写进去的结论是“越靠近部署越在意、越靠近内容越不管”。这张表把它推翻了——可视化建站工具离部署远得很，却是唯一一个全员登记的档。

分界线落在另一处：这家平台有没有把“客户之间互不信任”当成自己的风险。前端托管和建站工具的客户是一群素不相识的人，同一个域名底下的邻居随时可能是对手；Headless CMS和电商SaaS的默认心智则是“我的用户是编辑和店主，都是自己人”。

三组平台对照说明了什么

比例之外，几组具体的对照更能说明问题。

第一组，同行不同命。Headless CMS这一档里，Strapi登记了strapiapp.com，而且连媒体子域media.strapiapp.com都单独登记了一条；Contentful登记了预览用的ctfcloud.net。而Sanity、Storyblok、Prismic、Hygraph、Directus、Payload、Ghost、Kontent.ai、TinaCMS——搜遍整份清单，一条都没有。同一个品类、同一批客户、完全相反的选择。

之前拆这三家在SEO上的六个维度差异时，比的是渲染模式、结构化数据、多语言这些看得见的东西。域名边界这一层，当时压根没进视野。

第二组，同一家公司的两个域。Shopify登记了myshopify.com，实测在真实商店页面上写domain=myshopify.com的Cookie会被浏览器拒绝，隔离是实打实的。但它的预览域shopifypreview.com不在清单里。正式域隔离，预览域不隔离，而预览链接恰恰是最容易被随手转发出去的那一类。

第三组，换了域名之后。WP Engine在清单里有两条，wpenginepowered.com和js.wpenginepowered.com，都是新域。旧域wpengine.com至今一条都没有。这说明他们知道该登记——只是登记的是新域，老客户还留在没登记的那一边。

最后一组对照最有画面感：两大托管博客平台，Google的blogspot.com在清单里，而wordpress.com一条都没有。同样是让千万人开博客的地方，一个划了边界，一个没划。

查表时踩到的一个同名坑

第一版统计我是按关键词搜的，搜payload命中了一条payload.dev，于是把Payload这家CMS记成了“已登记”。回头核对提交方才发现，payload.dev是Figma提交的，跟那家CMS毫无关系。同名撞车让整档的登记率算高了一截。

教训是：判定一个平台在不在清单里，必须拿它实际分给客户的那个域去查，再回头看这条规则是谁提交的，两头都对上才算数。光搜品牌名，撞上重名就会得出反过来的结论。

跨租户Cookie实验在真实浏览器里测出了什么？

上面全是查表推出来的。查表会不会和浏览器的实际行为对不上？这必须实测。

实验设计与判据

用自动化控制两个浏览器：本机真实的Chrome 150，以及自动化套件自带的Chromium 148。全程无痕上下文，写入的探针叫d75probe，值固定为1，不含任何有意义的信息，每组跑完清空。判据是写入是否被浏览器接受，以及换一个租户站之后还读不读得到。

七项全中，Chrome 150与Chromium 148结果逐条一致。查表推导和浏览器实际行为完全对得上，说明这套判定是真在跑的代码，不只停留在纸面规范。

A组不止是“读得到”

A组的第一步很平淡：在一个租户站上写下带平台注册域的Cookie，浏览器接受了，Cookie罐里那条记录的域字段是.wordpress.com。

第二步才是关键。导航到另一个完全不相干的租户站之后，我没有只看JS能不能读到，而是把这一次导航发出的全部请求的Cookie头都抓了下来。16个请求带着这条探针发了出去，其中1条是顶层文档请求。这条Cookie不只是躺在浏览器里能被读一读——浏览器主动把它送到了另一家租户的服务器上。

抓到的那条请求头长这样（截断处理）：

Cookie: tk_ai=SqN%2F70%2FcHp3rLY%2F92R913HGz; tk_qs=; ccpa_applies=false;
        usprivacy=1---; wordads_uid=d8o85roq1785246922893; d75probe=1

探针在最后一位。但请注意它前面那几位。

平台自己在共享边界上写了哪些Cookie？

上面那条请求头里，d75probe是我放的，其余几条不是。这就引出了一个更实际的问题：既然这条边界是共享的，平台自己有没有在用它？

五年有效期的跨租户标识

我直接看了几个平台首页的响应头。dailypost.wordpress.com下发了6条Cookie，其中一条是这样的：

tk_ai=...; expires=Sun, 27 Jul 2031 13:47:47 GMT; Max-Age=157680000;
path=/; domain=.wordpress.com; secure

Max-Age是157680000秒，折合整整5年。域属性写的是.wordpress.com，意味着它对每一个租户站都有效。另一家建站平台也是同样的路数，下发一条Domain=.squarespace.com、有效期到2027年的标识。

再回头看那条跨租户请求头里的wordads_uid，名字已经说明了用途。这条共享边界不是没人注意到的疏漏，它是平台产品设计里明明白白在用的一块地基。

这条边界为什么难改

到这一步，很容易冒出一句“那赶紧去申请登记啊”。但请把因果关系再理一遍：一旦这个域进了PSL，平台自己那套跨租户的标识、统计和广告归因，第二天就全断了。

所以这不是待办事项被忘了：平台有理由不去做这个动作。你作为租户，等的是一个和你利益并不一致的决定。凡是“某个开关只能由别人来拨、而那个人拨了会亏”的场景，等是等不来的，只能绕。

浏览器内置的PSL快照为什么滞后四个月？

写到这儿我本来准备收尾了。结果一个念头冒出来：浏览器里的PSL是从哪来的？

去翻了Chromium源码里对应目录的说明，第一句话就是关键——这个目录存放的是“Chromium对公共后缀列表的一份拷贝”。拷贝，即随浏览器一起发布的快照，不做实时查询。

如何测出一份看不见的快照

问题来了：怎么知道这份拷贝停在哪一天？

PSL没有暴露任何查询接口，浏览器也不会告诉你它内置的版本号。我用的办法是把域名伪造出来：用自动化工具的路由拦截，把所有请求都截下来返回一个空白页面，这样https://tenant-a.任意后缀/都能正常打开，而浏览器对这个页面的源判定、Cookie判定，全部按真实规则走。

接着对每个待测后缀执行同一个动作：在tenant-a.某后缀上写domain=某后缀。被拒说明浏览器认它是公共后缀，写进去说明不认。一个动作，直接读出浏览器内置快照里有没有这条规则。

时间窗测试把分界线卡得很干净

先拉了从2024年初到现在的9个PSL历史版本，算出每个时间窗新增了哪些规则，然后每窗抽5条去测：

另外还测了7条根本不在清单里的域名当阴性对照，两个浏览器都是0认出——说明这套测法不会造假阳性。

结论没有任何模糊地带：2026年4月1日之前进入PSL的规则，40条测40条全部生效；4月1日之后进入的，15条测15条全部无效。今天是7月28日，滞后至少4个月，期间已经合入清单的112条规则，在这两个浏览器里一条都还没开始工作。

升级浏览器不等于更新清单

最反直觉的一条在这里：Chrome 150是当前的稳定版，Chromium 148比它落后两个大版本，两者的PSL快照却完全一样。

这意味着“让用户升级浏览器”根本解决不了这个问题——版本号涨了，清单不一定跟着走。PSL官方的说明页里早就把风险写了出来，措辞相当不客气：有人拿PSL来判断一个域名是不是有效域名，“This is dangerous”；如果以静态方式集成、又不定期更新，软件就会把有效的顶级域判成无效，或者把已经退役的当成有效。

这段警告的主语是“集成PSL的软件”，而浏览器正是最大的那一个。

申请把域名登记进PSL要走哪些流程、排多久？

假设你就是那家没登记的平台，现在决心补上，流程是什么样？

准入门槛比想象中高

官方指南要求先证明你确实控制这个域名，首选办法是加一条名为_psl的DNS文本记录，内容指向你那个合并请求的链接。还有一条容易被忽略的硬要求：提交的域名，注册到期日必须比提交日晚2年以上，注册期不足一年的可能被直接移除。

这两条相当合理——它筛掉的正是那些“用完就扔”的域名。

队列有多长

我去仓库现拉了数据。截至2026年7月28日：

中位数7天看着挺客气，平均值28.4天暴露了长尾。队列里躺着的名字并不都是小公司——某云厂商2026年第二季度的批量提交排了168天，某知名营销平台的申请排了91天。

官方指南对此的表述非常坦率，原文是全大写的：“There are NO SERVICE LEVEL AGREEMENTS ON TIME”，没有任何时效承诺，也不要期待处理速度或紧急通道。维护这份文件的是一群志愿者，而全球浏览器都在用它。

两段延迟是要叠加的

这里有个很容易算错的账。合并进清单不等于生效，合并之后还要等浏览器把新快照打包发布，而上一节实测出来的这一段是4个月。

两段加起来：中位37天的排队，加上4个月的快照滞后。今天决定要划这条边界，用户的浏览器真正开始执行它，保守估计要等半年。做技术方案的时候，把这半年算进去，比事后解释为什么“我们明明登记了”要省事得多。

PSL规则被增删时，已有Cookie会怎样？

清单不是只增不减的。把历史版本对比一遍就能看到它一直在两个方向上动：

加进去：原本能跨的突然跨不了

一个域被加进PSL，效果是立刻把它变成一堵墙。原先写在这一层上的Cookie，规范里说得很明确：如果清单的变化导致某条Cookie的域变成了公共后缀，那么这条Cookie就被视为无效。

请注意这句话的时态。它作用于已经存在的Cookie，不是只影响以后新写的。用户浏览器里躺着的登录态，可能在某天升级浏览器之后集体作废，而你的服务端日志上什么都看不到——只会看到一批老用户忽然都变成了新访客。

移出来：原本隔开的突然并成一家

反方向更危险，而且一年发生83次。一个域从清单里被删掉，意味着此前被隔离的租户，从某个浏览器版本起开始共用一个Cookie罐。

没有任何报错、没有任何告警、你的监控面板一片绿色。安全边界消失这件事，在被动一方那里是完全静默的。把PSL当成安全边界因此要格外谨慎——它由第三方维护，可以在你不知情的情况下被移动。

Headless架构下，站点边界卡在哪几个落点？

回到开头那个客户的问题。Headless的部署形态天然是多域的，边界问题因此被放大了好几倍。保哥手上那个上线半年又回滚的案子复盘时列了三本账——成本、工序、团队，现在回头看，还漏了一本：域名边界这本账，当时压根没人记。

八个具体的落点

SEO这一侧也别漏

技术侧之外，还有几件和搜索直接相关的。Headless上线时那套要自己重搭的SEO基建里，站点地图和重定向是明面上的活；域名边界是暗面上的活，它不报错，但会让你的规范网址判定指向一个你没打算对外的域。

还有一件容易搞混的事：SEO意义上的“子域还是子目录”，和浏览器意义上的“是不是同一个站”，是两套完全不相干的判定。前者讨论的是权重怎么传导，后者讨论的是Cookie能不能过去。同一个架构决策，两套评价体系，别拿一套的结论去回答另一套的问题。

上线前如何把域名边界与会话方案一次定死？

最后落到可执行的部分。下面这套顺序，保哥现在给客户做架构评审时是照着走的。

三条一分钟就能查完的

1. 把你正在用的每一个平台默认域抄下来，去清单里搜一遍。直接在PSL原文里搜字符串就行，几秒钟出结果。搜不到，就按“所有客户共用一个站”来设计。
2. 在租户站的控制台里试着往平台注册域写一条Cookie。写进去了，说明边界不存在；被拒了，说明生效。这一步比查表更可信，因为它测的是用户那台浏览器的真实行为。
3. 看一眼平台自己下发的Cookie的域属性。如果平台自己就在往共享域上写长期标识，那么这个边界短期内不会有变化。

域名规划的两条原则

第一条，凡是要带登录态的，全部收进你自己的注册域。前端www、接口api、预览preview、后台admin，都挂在自有域的子域上。这样一来边界是你自己划的，不依赖任何第三方的清单，也不用等半年。托管平台给的默认域只当部署产物，不当业务入口。这条和出海站选ccTLD、子目录还是子域名那套决策并不冲突——那边定的是内容怎么分，这边定的是会话怎么走，两件事分开定，再看有没有打架。

第二条，接受“跨站”是常态，别指望靠Cookie把它抹平。如果架构上确实必须跨站，那就从一开始按跨站设计：令牌走请求头、会话不依赖顶层域的Cookie、需要传状态的地方显式传。前端框架的渲染模式选择要和这条一起定，因为它决定了鉴权发生在服务端还是浏览器端。

三件别做的事

别把PSL当成一份可以实时查询的权威源。它是一份缓存，你面前每个用户手里那份的版本都不一样。任何“我查了PSL所以一定如何”的推理，都得先问一句：查的是谁那份？

别把它当安全边界的唯一凭据。它由志愿者维护、可被移除、你收不到通知。真正的隔离要靠你自己的鉴权，PSL最多算一层附赠的保险。

别在没测过的情况下相信任何解析库的结论。库里也是快照，而且往往比浏览器还旧。要判断真实行为，就去真实浏览器里写一条Cookie试试——这件事的成本是30秒。

常见问题解答

我用的托管平台不在清单里，是不是必须立刻换掉？

不必然。要看你在那个域上放了什么。如果它只承载静态展示、没有登录态、没有敏感Cookie，那么共用边界的实际影响很小。真正需要动的是两类：一类是在平台默认域上跑带登录的预览或后台，另一类是把用户的支付、账号相关流程放在了平台默认域上。这两类应该尽快迁到自有注册域的子域下。判断顺序是先看“这个域上有没有会话”，再决定要不要动，而不是一看到未登记就全盘重构。

我自己的公司域名需要去申请加入PSL吗？

绝大多数情况不需要，而且不该申请。PSL的PRIVATE段是给“把子域分发给互不信任的第三方”的平台准备的，比如托管商、动态DNS服务商、多租户SaaS。如果你的子域都是自己人在用，加进去反而会让你自己的跨子域Cookie直接失效，属于自伤。官方指南也明确表示，服务用户数达不到规模的项目大概率会被拒。判据很简单：你的子域会不会交给你不信任的人？不会，就别去排这个队。

预览域和正式域不同站，除了重新登录还有别的后果吗？

有，而且更隐蔽。同意管理平台的选择记录通常存在Cookie里，跨不过去就会在预览环境反复弹窗，编辑很容易顺手点掉，导致预览环境的统计口径和线上不一致。此外，如果预览环境要调用正式环境的接口，浏览器会把这次调用判成跨站，Sec-Fetch-Site的值随之改变，服务端如果做了基于这个头的校验就会开始拒绝。还有一层是缓存分区：不同站意味着不同的分区键，预览环境的资源缓存不会复用正式站的，首屏会明显慢一截。

怎么快速判断一个域名的eTLD+1到底是什么？

最省事也最可信的办法是在目标域的页面上打开控制台，试着往你猜测的那一层写Cookie，写得进去说明它不是公共后缀。查表当然也行，但要注意查的那份表和用户浏览器里的那份可能差着几个月。另外提醒一句，很多现成的域名解析工具用的是自带快照，判断新域名时容易出错，做批量根域名提取这类工作时，遇到近期新增的后缀要额外核对一遍。

浏览器快照滞后4个月，这个数字会一直是4个月吗？

不会，它是浮动的，而且没有公开的承诺周期。本文测的是2026年7月底的两个具体版本，测出来的分界线落在4月初。下次再测很可能是另一个数字。真正要记住的不是“4个月”这个值，而是这个延迟客观存在、量级是月而不是天，并且升级浏览器版本并不保证它会缩短。做方案时按季度量级留余量，比盯着某个具体数字更稳妥。

已经在共享边界上跑了一段时间，怎么收拾？

分三步。第一步止血：把新的登录态、支付态全部迁到自有注册域的子域，不要在共享域上再产生新的会话。第二步清理：给共享域上已经写出去的Cookie发一轮删除指令，也就是重发同名同属性、寿命为0的Cookie，这一步必须把域属性写得和当初完全一致，否则删不掉。第三步验证：用无痕窗口走一遍完整流程，确认新会话的Cookie域字段是你自己的域。整个过程不需要停机，但顺序不能反——先迁再清，反过来会把在线用户直接踢下线。

权威参考资料