网站运营中图片防盗链的Referer校验与空值处理

图片防盗链本质上是资源权限的博弈。很多运营者以为在服务器上配了Referer白名单就万事大吉，结果线上图片要么被第三方浏览器插件直接破了防，要么自家App的请求因为Referer为空被拦截，导致页面一片空白。Referer校验的漏洞和空值处理不当，是图片资源被恶意消耗、服务器带宽被薅羊毛的直接原因。解决这个问题不能只靠一两条规则，需要从校验逻辑的严谨性、空值场景的兜底策略、以及多层防御的叠加三个维度去构建体系。

Referer校验的核心在于HTTP请求头中的Referer字段。当浏览器发起图片请求时，服务器检查这个字段是否来自允许的域名。逻辑很简单：如果Referer是https://www.yourdomain.com，就放行；如果是https://www.other.com，就拦截。但问题在于Referer字段太容易被操控。浏览器插件、代理工具、甚至直接在地址栏敲回车，都能让Referer消失或伪造。更致命的是，HTTPS协议下，从HTTPS页面跳转到HTTP资源时，浏览器默认不发送Referer，这是安全策略，不是Bug。所以单纯依赖Referer校验，误伤率和漏网率都高得离谱。

空Referer不是偶然，而是高频事件。第一种场景是用户直接在浏览器地址栏输入图片URL并回车，此时请求头里没有Referer。第二种是HTTPS页面引用了HTTP协议的图片，出于安全降级策略，浏览器主动去掉了Referer。第三种是某些安全软件、防火墙或者浏览器的隐私模式，会强制清除Referer。如果服务器对空Referer一律拒绝，那所有来自HTTPS站点的图片引用都会挂掉，包括你自己的站点如果做了全站HTTPS化，某些老页面里还残留HTTP图片链接，也会自残。正确的做法是对空Referer做分级处理：对于核心品牌图片、高成本原创图，可以直接拒绝；对于通用素材、图标类图片，可以放行但要配合其他校验手段，比如请求频率限制。

Nginx是实现Referer校验最直接的战场。一个典型的配置不是简单写死域名，而是用正则做灵活匹配，同时把空Referer单独拎出来处理。核心逻辑是：先判断Referer是否为空，如果为空且请求的是受保护目录，则返回403或替换为占位图；如果不为空，再提取Referer中的域名部分，与白名单做精确比对。这里有个容易被忽略的细节：Referer可能包含端口号，比如https://www.yourdomain.com:443，所以匹配时要去掉端口，只比较主机名。另外，白名单里除了自己的主域名，还要加上搜索引擎的域名，因为图片搜索会引用你的图片，如果拦截了百度图片搜索的Referer，等于自断流量。

location ~* \.(jpg|jpeg|png|gif|webp)$ {
    valid_referers none blocked yourdomain.com *.yourdomain.com;
    if ($invalid_referer) {
        return 403;
    }
}

上面这段配置看似标准，但valid_referers里的none代表允许空Referer，blocked代表允许没有Referer头的请求，这两项如果都加上，防盗链基本形同虚设。更精细的做法是不用none和blocked，而是用变量$http_referer做自定义判断。先判断$http_referer是否为空字符串，再决定是否放行。对于空Referer请求，可以返回一张带有水印的小尺寸缩略图，而不是直接403，这样既保护了原图，又不至于让正常用户看到破碎的图片图标。

当Referer为空且请求的是高价值图片时，直接返回403在用户体验上是灾难。更好的做法是返回一张默认占位图，这张图可以是一张带有你网站Logo的提示图，告诉用户“该图片仅限本站浏览”。Nginx里用rewrite或try_files把被拦截的请求重定向到一张固定图片上。更进一步，可以在应用层做动态水印处理。当Referer校验失败时，不返回原图，而是实时给图片加上半透明水印再输出。这样即使图片被第三方站点引用，也能起到品牌曝光的作用，把盗链变成被动推广。动态水印对服务器性能有消耗，所以通常只对高分辨率原图做这个处理，缩略图直接返回占位图即可。

很多网站图片都走了CDN，如果在源站做Referer校验，CDN缓存下来的可能是403页面或者占位图，导致正常用户也看到错误内容。正确的做法是把Referer校验规则配置在CDN边缘节点上，而不是源站。CDN厂商通常提供Referer防盗链配置，可以设置白名单和空Referer的处理方式。但要注意CDN的缓存Key策略：如果缓存Key不包含Referer信息，那么第一个请求如果是空Referer被拒绝，后续正常Referer的请求也会命中这个被拒绝的缓存。解决方法是把Referer加入缓存Key的组成部分，或者对空Referer请求直接回源，不缓存其结果。这需要CDN支持自定义缓存规则，配置时务必和运维确认清楚。

在App和小程序里，WebView发起图片请求时可以自定义Referer字段，这意味着攻击者可以轻松伪造Referer。很多运营者发现，即使服务器配了严格的Referer白名单，图片依然被第三方App大量调用。这是因为客户端代码可以设置Referer为任何值，包括你的域名。针对这种情况，单纯的Referer校验已经失效，必须叠加User-Agent校验和业务自定义Header。比如在App端发起图片请求时，除了Referer，还带上一个动态生成的Token，这个Token由客户端根据时间戳和密钥生成，服务器验证Token的有效性。虽然客户端代码可以被反编译，但增加了破解成本，能挡住大部分低水平盗链。

最近几年主流浏览器都在收紧Referer策略。Chrome默认把Referer策略从no-referrer-when-downgrade改成了strict-origin-when-cross-origin，这意味着跨域请求时Referer只包含源域名，不包含完整的路径和参数。对于图片防盗链来说，这其实是好事，因为域名部分还在，校验依然有效。但Safari和Firefox在某些隐私模式下会直接去掉Referer，导致空Referer请求比例大幅上升。如果你的网站用户群体里苹果设备占比高，空Referer的处理策略就必须更宽松，否则大量正常用户会看到图片加载失败。可以通过分析日志，统计空Referer请求中User-Agent的分布，如果大部分是Safari的iPhone用户，那就要调整策略，不能一刀切拒绝。

防盗链策略不是配完就一劳永逸，需要持续监控。Nginx的access_log里记录了每个图片请求的Referer和状态码，通过分析这些日志，可以发现异常的流量模式。比如某个IP在短时间内大量请求图片，且Referer都是空或者伪造的，这大概率是爬虫或者盗链工具。可以写脚本定时分析日志，把高频盗链的IP加入临时黑名单，在Nginx里用deny指令封禁。更进一步，可以用ELK或者类似日志分析平台，实时监控图片流量的Referer分布，当空Referer或非白名单Referer的请求占比突然飙升时，触发告警，及时调整策略。

单一依赖Referer校验是脆弱的，有效的图片防盗链必须是多层防御。第一层在CDN边缘节点做Referer白名单和空Referer处理，拦截掉大部分明显的盗链。第二层在源站Nginx做更精细的校验，包括Referer域名提取、端口处理、以及针对特定目录的特殊规则。第三层在应用层对高价值图片做动态Token校验，Token可以放在URL参数里，也可以放在自定义Header里，有效期设短，比如5分钟，过期即失效。第四层是日志分析和IP黑名单，对持续盗链的IP做自动化封禁。四层叠加下来，攻击者要绕过需要付出很高的成本，而正常用户的误伤率可以控制在极低水平。

很多人在Nginx里用if指令做Referer判断，但if在location里使用有副作用，可能导致意外行为。更稳妥的方式是用map指令在http块里定义Referer映射，然后在location里引用。另一个常见错误是白名单里只写了不带www的域名，结果www开头的子域名请求被拦截。白名单要同时包含yourdomain.com和www.yourdomain.com，如果有多个子域名，也要一并加入。还有人在正则里用了.*的宽松匹配，导致子域名劫持风险，比如attackeryourdomain.com也能通过校验。正确做法是用\.转义点号，用$锚定结尾，确保精确匹配。

map $http_referer $referer_valid {
    default 0;
    "~*^https?://(www\.)?yourdomain\.com" 1;
    "~*^https?://cdn\.yourdomain\.com" 1;
    "" 2;  # 空Referer标记为2，单独处理
}

server {
    location ~* \.(jpg|png|gif|webp)$ {
        if ($referer_valid = 0) {
            return 403;
        }
        if ($referer_valid = 2) {
            rewrite ^ /placeholder.jpg last;
        }
    }
}

这段配置用map把Referer校验结果映射为数字，0表示非法，1表示合法，2表示空Referer。在location里根据不同的值做不同处理，逻辑清晰，避免了if嵌套的混乱。空Referer请求被重定向到placeholder.jpg，而不是直接403，用户体验更好。

图片搜索是很多网站的重要流量来源，如果拦截了搜索引擎的Referer，等于自断臂膀。百度图片搜索的Referer通常包含image.baidu.com，搜狗图片搜索是pic.sogou.com，360图片搜索是image.so.com。这些域名要加入白名单。但要注意，搜索引擎的Referer也可能被伪造，所以对搜索引擎的放行要配合User-Agent校验，确认请求确实来自搜索引擎的爬虫。百度蜘蛛的User-Agent包含Baiduspider，搜狗是Sogou Pic Spider，360是360Spider。把Referer和User-Agent结合起来判断，能有效防止伪装成搜索引擎流量的盗链行为。

不是所有图片都值得用同样的防盗链强度去保护。把图片资源分成三个等级：高价值原创图，比如产品实拍图、设计稿、付费素材，用最严格的Token校验加动态水印；中等价值图片，比如文章配图、截图，用Referer白名单加空Referer返回占位图；低价值图片，比如图标、按钮背景、通用装饰图，可以不做防盗链，甚至欢迎第三方引用，因为这些图片的传播能带来反向链接和品牌曝光。分层之后，服务器资源消耗和用户体验之间能取得更好的平衡，也避免了因为过度保护低价值图片而影响页面加载速度。

随着浏览器隐私保护的加强，Referer字段的可用性在逐步降低。Chrome已经在推广Referrer-Policy，允许网站通过响应头控制Referer的发送策略。Same-Origin、Strict-Origin、No-Referrer这些策略让网站开发者可以主动限制Referer的发送，但这也意味着第三方站点可以故意不发送Referer来绕过你的防盗链。未来图片防盗链会更依赖Origin头、自定义Token、以及浏览器端的数字水印技术。Origin头与Referer类似，但只包含协议和域名，不包含路径，隐私性更好，且浏览器对其限制更少。在服务端同时校验Origin和Referer，能提高防盗链的可靠性。

图片防盗链从来不是一个纯技术问题，而是成本、体验、安全的三角平衡。Referer校验是最基础的防线，空值处理决定了这条防线是铜墙铁壁还是伤敌一千自损八百。把空Referer当成一种需要精细化应对的场景，而不是简单的允许或拒绝，配合CDN策略、动态水印、Token校验和日志监控，才能在不牺牲用户体验的前提下，把图片资源的控制权牢牢握在自己手里。