Referer 的现实困境

# 引荐来源的现实 来源：https://www.robinsloan.com/lab/referer/ 2026年5月10日 Chris Morgan 已经厌倦了人们在附加查询字符串（https://chrismorgan.info/no-query-strings）到他 URL 上的行为——例如 `www.robinsloan.com/lab/?like=this&and=this`——因此他配置网站直接拒绝此类请求，而不是默默忍受。 当然，任何人都可以自由地按照自己的喜好配置服务器……然而，Chris 是这样写的： > 如果我想知道[访问者来自哪里]，我会查看 Referrer 头部；如果它不存在，那肯定是有正当理由的。 这已经不再完全属实了。对于大多数网站而言，大多数——不仅仅是多数，而是真正的大多数——访问者是通过点击电子邮件或应用程序内的链接而来的（例如 Instagram、iOS 上的信息、Substack 应用），而这些来源均不会设置 `Referrer` 头部；因此，所有这类访问者都被归类到一个庞大的类别中，称为*直接访问（Direct）*或*未知（Unknown）*。 这种机制的失效促使我在所有外发链接后附加自定义查询字符串 `utm_source=Robin_Sloan_sent_me`：考虑到我分享的链接中，许多/大多数点击将来自我的电子邮件通讯，我希望来源清晰可见，特别是在像 Shopify 这样的场景中。 这并不是说 Chris Morgan 应该做出任何*不同*的改变——坚持己见的运营者决策让互联网运转——而是提供了一个澄清当前局势的机会。 我不会收集或审查任何类型的网站分析数据，所以我并不是这类引荐信息的消费者。即便如此，我认为我的自定义查询字符串是一种数字礼仪的体现：与其将一堆匿名流量倾倒在别人的门口，不如揭示链接的来源，以便网站或在线商店运营者可以追溯并联系，如果有意或需要的话。（值得一提的是，这在 Abrams 天文馆（https://abramsplanetarium.natsci.msu.edu/sky-calendar/index.aspx?utm_source=Robin_Sloan_sent_me）收到一波新订阅请求时非常有用，他们不确定这些请求是否合法；简短的邮件沟通让他们确信，是的，这些人都是真实的……他们都是极客……他们想要 Sky Calendar！） 请注意，少数站点会因为意外的查询字符串而出错，包括 YouTube（！），所以我维护了一个例外列表，现在其中也加入了 `chrismorgan.info`。 返回博客主页（https://www.robinsloan.com/lab/）