PSL 这两年收紧得很明显，想把自己的后缀送进列表，首先要搞清楚一件事：你是在为整条互联网的生态链负责。

下面这几点，可以当自查清单来用。

首先，为什么往 PSL 里加一行后缀不是件小事

很多人低估了 PSL 的权重：

你随手加的一条后缀记录，实际上会被几乎所有主流浏览器、邮件客户端、密码管理器、安全产品以及无数后端服务同步和加载。每次浏览器解析 cookie 边界、计算缓存分片、做站点隔离、判断跨站脚本范围，都要依赖这份列表；一条新的后缀，会立刻影响到全球数十亿设备在这些逻辑上的行为路径和判断分支。

哪怕只是多了一行字符串，也意味着：

• 每次 URL 解析和「注册域」计算时，多一次匹配、更复杂的规则判断，长期累积就是巨量 CPU 时间和内存占用的变化
• 安全策略（比如 SameSite cookie、站点隔离、HSTS 等）的边界会随之改变，如果后缀质量不高，就有可能放大滥用面或制造新的攻击切入口

所以从维护者视角看，每一个新进入 PSL 的后缀，都是对全球基础设施增加了一个「必须永远考虑的特殊分支」。如果运营者不成熟（刚开业几个月就倒闭跑路）、滥用多，那代价不是只有你自己在付，而是把所有实现了 PSL 的软件一起拖下水。

动机 & 底线

• 不要造假！！！ 审核 PSL 的大多是安全工程师。用户数、二级域名数量、活跃度，这些东西一旦动歪脑筋，很容易从日志、公开数据和站点质量上被看穿。
• 涉灰、涉黑的历史域名就别拿去申请了。最近就有 MJJ 拿做过伪造学生证的域名、实际几乎没真实用户的后缀去提 PR 的案例（围观 → Add frp.gs to the PRIVATE section by frpAbuse · Pull Request #2685 · publicsuffix/list · GitHub ），还在说明里对社区撒谎，这种行为只会拉低整个中文社区在 PSL 的信誉，对后来者是纯负资产…
• 也不要号召用户去 PSL 发帖这种奇奇怪怪的操作，失败案例 → Add com.mp by serverless-domain-registry · Pull Request #1993 · publicsuffix/list · GitHub

不要把 PSL 和 Cloudflare 当宣传的噱头

• 宣传的时候最好别拿「能上 Cloudflare」「能进 PSL」当卖点，不诚信案例 → https://www.nodeseek.com/post-428964-1#14
• 更不要为了「搞到 PSL 资格」去招揽一堆不受控的用户，eu.cc 就是一个例子，因为滥用过多，被安全厂商标记，导致引发了 PSL 社区的质疑 → [Add[uk.cc ec.cc eu.cc gu.cc us.cc]to PSL by Emma524 · Pull Request #2515 · publicsuffix/list · GitHub](https://github.com/publicsuffix/list/pull/2515#issuecomment-3038774285)
• 现实情况是：现在任何正常域名都可以用 Cloudflare SaaS 方式接入，是否在 PSL 里，和以前相比已经没那么关键了；对用户来说，只是少写几条 DNS 记录、图个省事
• PSL 存在的主要意义，是让浏览器等组件能正确识别「注册域 vs 子域」，提高安全性和隔离度，从而让用户更放心地使用你的二级分发服务

申请前必须做的自查

这些检查自己不做，审核时别人也很可能会做：

• Google site: 自查内容风险
  用 site:你的后缀 搜一遍，看用户有没有架设明显违规、诈骗、钓鱼之类的网站。比如：

  • site:us.kg https://www.google.com/search?q=site%3Aus.kg
  • site:gu.cc https://www.google.com/search?q=site%3Agu.cc
    如果第一页就一堆奇怪内容，先处理滥用，再谈 PSL

• crt.sh 看证书规模
  看看实际有多少子域发过证书，大概能侧面反映真实使用量：

  • 以 gu.cc 为例：https://crt.sh/?identity=gu.cc&exclude=expired&dir=^&sort=1&group=icaid
  • 以 us.kg 为例：https://crt.sh/?identity=us.kg&exclude=expired&dir=^&sort=1&group=icaid
    一般来说，几百到上千个有证书的子域，才算勉强有点「公共服务」的样子，否则会被质疑是不是只搞了几个样板站。
• 子域收集站自查
  用诸如 subdomainfinder.c99.nl 之类的工具，看真实被发现的子域大概有多少，是否和你对外宣称的数量差不多？
• VirusTotal 等风控平台
  丢进 VirusTotal 之类的平台看看整体信誉情况，一两个红黄没关系，但如果大面积红黄警告，先处理被警告的子域名。

看 PR 队列的时机选择

看看 PSL 仓库当前的 PR 队列 → Pull requests · publicsuffix/list · GitHub

如果 open 的 PR 已经堆了超过 10 几个，这个时候你新提一个，很可能排队时间超级长，而且越到后面、越容易被更严格地审视。

耐心一点，等到积压队列在 10 个以下时申请会相对更好。

官网和运营侧

• 官网信息要足够完整：介绍、使用条款、隐私/滥用处理说明、联系邮箱，这些最基本的信息不能缺。UI 不要求「高大上」，但至少要让人觉得这是个认真运营的服务，不是一个随手做的 landing。 失败案例 → ADD int.yt to PSL by Gamming-SERVICE · Pull Request #2670 · publicsuffix/list · GitHub
• 滥用举报入口要清晰：在官网显眼位置给出 abuse 联系方式（邮箱表单都行），并说明处理流程和预期响应时间。
• 域名一致性：如果你的后缀是 mjj.com，而官网是 mjjzone.com，那至少要保证访问 mjj.com 会 301/302 到 mjjzone.com，并在跳转后页面上也能清楚看到滥用举报等信息

认真读完官方指南和模板

• 先完整读一遍官方的 Guidelines：Guidelines · publicsuffix/list Wiki · GitHub
• 里面很多细节其实都对应着社区历史上踩过的坑。
• 看不懂的地方就老老实实用翻译工具，逐条消化。

• PR 模板要写完整：

  • 可以用 AI 帮忙润色结构、补全英文，但不要一上来就贴一堆一看就是 ai 搓的官话。
  • 模板里的每个问题，应该结合你自己的运营数据、治理措施、目标用户来回答，而不是套模板、空话连篇。
  • 如果你自己都说不清楚「为什么你这个后缀值得被信任」，那审核人也很难被说服。

下游更新时间不在 PSL 手上

确保第一次 PR 尽量正确，因为每一次改动都会在数十亿设备上走一轮漫长的传播过程，错一次，就多一轮不一致的窗口期。

很多产品会定期「抓一份 PSL 快照」打包进自己的浏览器、操作系统、SDK 或安全组件里，更新周期可能是几天、几周，也可能要等到下一次系统/应用大版本更新。

MJJ 们经常说的 Cloudflare 拉取 PSL 也是同理。

• 图里 A、B、C、D 代表不同的第三方：浏览器、操作系统、DNS 组件、SDK 库等等，它们各自在不同时间点拉取 PSL、打包、发版本。
• 横轴是时间（不按具体单位），能看到：PSL 仓库合并之后，不同下游在不同时间点才「看到」变更，有的甚至要等很久，整个扩散过程像瀑布一样一层层往下流。

• 如果第一次 PR 合并后发现有问题，需要第二次 PR 修正或回滚，那么这两次变更会各自沿着同样的瀑布路径向下游扩散。
• 结果就是：在某一段时间里，不同产品、不同版本之间，对同一个后缀的认知可能完全不一致，有的吃到了 PR1，有的已经吃到了 PR2，有的还停在「没变更之前」。

总之

想进名单没问题，但前提是你愿意、也有能力对自己的后缀和整条生态负责，而不是拿着一个后缀到处薅 Cloudflare 的羊毛。

来源

文章来源: https://www.nodeloc.com/t/topic/69531