慣性聚合 高效追蹤和閱讀你感興趣的部落格、新聞、科技資訊
閱讀原文 在慣性聚合中打開

推薦訂閱源

博客园 - 司徒正美
V
V2EX
T
Tailwind CSS Blog
有赞技术团队
有赞技术团队
aimingoo的专栏
aimingoo的专栏
Apple Machine Learning Research
Apple Machine Learning Research
IT之家
IT之家
Blog — PlanetScale
Blog — PlanetScale
A
About on SuperTechFans
月光博客
月光博客
T
The Blog of Author Tim Ferriss
宝玉的分享
宝玉的分享
Martin Fowler
Martin Fowler
博客园 - 聂微东
The GitHub Blog
The GitHub Blog
V
Visual Studio Blog
WordPress大学
WordPress大学
酷 壳 – CoolShell
酷 壳 – CoolShell
Engineering at Meta
Engineering at Meta
GbyAI
GbyAI

阮一峰的网络日志

科技爱好者周刊(第 396 期):互联网通信的替代方案 科技爱好者周刊(第 396 期):互联网通信的替代方案 - 阮一峰的网络日志 科技爱好者周刊(第 395 期):软件开发的第三种方式 科技爱好者周刊(第 395 期):软件开发的第三种方式 - 阮一峰的网络日志 科技爱好者周刊(第 393 期):脑腐状态 科技爱好者周刊(第 392 期):axios 投毒与好莱坞式骗术 科技爱好者周刊(第 391 期):AI 的贫富分化 科技爱好者周刊(第 390 期):没有语料,大模型就是智障 套壳中国大模型撑起500亿美元估值?扒一扒 Cursor 的"套壳"疑云 科技爱好者周刊(第 389 期):未来如何招聘程序员 科技爱好者周刊(第 388 期):测试是新的护城河 零安装的"云养虾":ArkClaw 使用指南 科技爱好者周刊(第 387 期):你是领先的 科技爱好者周刊(第 386 期):当外卖员接入 AI 字节全家桶 Seed 2.0 + TRAE 玩转 Skill 科技爱好者周刊(第 385 期):马斯克害怕中国车企吗? 智谱旗舰 GLM-5 实测:对比 Opus 4.6 和 GPT-5.3-Codex 科技爱好者周刊(第 384 期):为什么软件股下跌 科技爱好者周刊(第 383 期):你是第几级 AI 编程 Kimi 的一体化,Manus 的分层 科技爱好者周刊(第 382 期):独立软件的黄昏 AI native Workspace 也许是智能体的下一阶段 科技爱好者周刊(第 381 期):中国 AI 大模型领导者在想什么 科技爱好者周刊(第 380 期):为什么人们拥抱"不对称收益" 科技爱好者周刊(第 379 期):《硅谷钢铁侠》摘录 我如何用 AI 处理历史遗留代码:MiniMax M2.1 升级体验 科技爱好者周刊(第 378 期):预测是新的互联网热点 科技爱好者周刊(第 377 期):14万美元的贫困线 科技爱好者周刊(第 376 期):太空数据中心的争议 科技爱好者周刊(第 375 期):一扇门的 Bug 终于有人做了 Subagent,TRAE 国内版 SOLO 模式来了 科技爱好者周刊(第 374 期):6GHz 的问题 VS Code 使用国产大模型 MiniMax M2 教程 科技爱好者周刊(第 373 期):数据模型是新产品的核心 国产大模型接入 Claude Code 教程:以 Doubao-Seed-Code 为例 科技爱好者周刊(第 372 期):软件界面如何设计 大模型比拼:MiniMax M2 vs GLM 4.6 vs Claude Sonnet 4.5 科技爱好者周刊(第 371 期):一个乐观主义者的专访 科技爱好者周刊(第 370 期):正确的代码高亮 错误处理:异常好于状态码 科技爱好者周刊(第 369 期):Tim 与罗永浩的对谈 科技爱好者周刊(第 368 期):不要这样管理软件团队 一天之内,智谱和 Anthropic 都发了最强编程模型 科技爱好者周刊(第 367 期):Nano Banana 的几个妙用 科技爱好者周刊(第 366 期):旧金山疯狂的 AI 广告 科技爱好者周刊(第 365 期):流量变现正在崩塌 科技爱好者周刊(第 364 期):最难还原的魔方 科技爱好者周刊(第 363 期):最好懂的神经网络解释 科技爱好者周刊(第 362 期):GitHub 工程师谈系统设计 科技爱好者周刊(第 361 期):暗网 Tor 安全吗?
HTTP Referer 教程
阮一峰 · 2019-06-04 · via 阮一峰的网络日志

HTTP 請求的頭信息裡面,Referer 是一個常見字段,提供訪問來源的信息。

很多開發者知道這個字段,但是說不清它的具體細節。本文詳細介紹該字段。

一、Referer 的含義

現實生活中,購買服務或加入會員的時候,往往要求提供信息:"你從哪裡知道了我們?"

這叫做引薦人(referrer),誰引薦了你?對於公司來說,這是很有用的信息。

互聯網也是一樣,你不會無緣無故訪問一個網頁,總是有人告訴你,可以去那裡看看。服務器也想知道,你的"引薦人"是誰?

HTTP 協議在請求(request)的頭信息裡面,設計了一個Referer字段,給出"引薦網頁"的 URL。

這個字段是可選的。客戶端發送請求的時候,自主決定是否加上該字段。

很有趣的是,這個字段的拼寫是錯的。Referer的正確拼寫是Referrer,但是寫入標準的時候,不知為何,沒人發現少了一個字母r。標準定案以後,只能將錯就錯,所有頭信息的該字段都一律錯誤拼寫成Referer

二、Referer 的發生場景

瀏覽器向服務器請求資源的時候,Referer字段的邏輯是這樣的,用戶在地址欄輸入網址,或者選中瀏覽器書籤,就不發送Referer字段。

主要是以下三種場景,會發送Referer字段。

(1)用戶點擊網頁上的鏈接。

(2)用戶發送表單。

(3)網頁加載靜態資源,比如加載圖片、腳本、樣式。


<!-- 加載圖片 -->
<img src="foo.jpg">
<!-- 加載腳本 -->
<script src="foo.js"></script>
<!-- 加載樣式 -->
<link href="foo.css" rel="stylesheet">

上面這些場景,瀏覽器都會將當前網址作為Referer字段,放在 HTTP 請求的頭信息發送。

瀏覽器的 JavaScript 引擎提供document.referrer屬性,可以查看當前頁面的引薦來源。注意,這裡採用的是正確拼寫。

三、Referer 的作用

Referer字段實際上告訴了服務器,用戶在訪問當前資源之前的位置。這往往可以用來用戶跟蹤。

一個典型的應用是,有些網站不允許圖片外鏈,只有自家的網站才能顯示圖片,外部網站加載圖片就會報錯。它的實現就是基於Referer字段,如果該字段的網址是自家網址,就放行。

由於涉及隱私,很多時候不適合發送Referer字段。

這裡舉兩個例子,都不適合暴露 URL。一個是功能 URL,即有的 URL 不要登錄,可以訪問,就能直接完成密碼重置、郵件退訂等功能。另一個是內網 URL,不希望外部用戶知道內網有這樣的地址。Referer字段很可能把這些 URL 暴露出去。

此外,還有一種特殊情況,需要定製Referer字段。比如社交網站上,用戶在對話中提到某個網址。這時,不希望暴露用戶所在的原始網址,但是可以暴露社交網站的域名,讓對方知道,是我貢獻了你的流量。

四、rel屬性

由於上一節的原因,瀏覽器提供一系列手段,允許改變默認的Referer行為。

對於用戶來說,可以改變瀏覽器本身的全局設置,也可以安裝瀏覽器擴展。這裡就不詳細介紹了。

對於開發者來說,rel="noreferrer"屬性是最簡單的一種方法。<a><area><form>三個標籤可以使用這個屬性,一旦使用,該元素就不會發送Referer字段。


<a href="..." rel="noreferrer" target="_blank">xxx</a>

上面鏈接點擊產生的 HTTP 請求,不會帶有Referer字段。

注意,rel="noreferrer"採用的是正確的拼寫。

五、Referrer Policy 的值

rel屬性只能定製單個元素的Referer行為,而且選擇比較少,只能發送或不發送。W3C 為此制定了更強大的 Referrer Policy

Referrer Policy 可以設定8個值。

(1)no-referrer

不發送Referer字段。

(2)no-referrer-when-downgrade

如果從 HTTPS 網址鏈接到 HTTP 網址,不發送Referer字段,其他情況發送(包括 HTTP 網址鏈接到 HTTP 網址)。這是瀏覽器的默認行為。

(3)same-origin

鏈接到同源網址(協議+域名+端口 都相同)時發送,否則不發送。注意,https://foo.com鏈接到http://foo.com也屬於跨域。

(4)origin

Referer字段一律只發送源信息(協議+域名+端口),不管是否跨域。

(5)strict-origin

如果從 HTTPS 網址鏈接到 HTTP 網址,不發送Referer字段,其他情況只發送源信息。

(6)origin-when-cross-origin

同源時,發送完整的Referer字段,跨域時發送源信息。

(7)strict-origin-when-cross-origin

同源時,發送完整的Referer字段;跨域時,如果 HTTPS 網址鏈接到 HTTP 網址,不發送Referer字段,否則發送源信息。

(8)unsafe-url

Referer字段包含源信息、路徑和查詢字符串,不包含錨點、用戶名和密碼。

六、Referrer Policy 的用法

Referrer Policy 有多種使用方法

(1)HTTP 頭信息

服務器發送網頁的時候,通過 HTTP 頭信息的Referrer-Policy告訴瀏覽器。


Referrer-Policy: origin

(2)<meta>標籤

也可以使用<meta>標籤,在網頁頭部設置。


<meta name="referrer" content="origin">

(3)referrerpolicy屬性

<a><area><img><iframe><link>標籤,可以設置referrerpolicy 屬性。


<a href="..." referrerpolicy="origin" target="_blank">xxx</a>

七、退出頁面重定向

還有一種比較老式的技巧,但是非常有效,可以隱藏掉原始網址,谷歌和 Facebook 都在使用這種方法。

鏈接的時候,不要直接跳轉,而是通過一個重定向網址,就像下面這樣。


<a  href="/exit.php?url=http%3A%2F%2Fexample.com">Example.com</a>

上面網址中,先跳轉到/exit.php,然後再跳轉到目標網址。這時,Referer字段就不會包含原始網址。

(完)