应分步迭代清理重构防盗链白名单：先识别失效项（如下线域名、测试地址等），再按用途分组精简逻辑，最后验证空referer兼容性及灰度上线。
清理和重构过时的防盗链白名单，核心是先识别失效项、再精简逻辑、最后验证兼容性。不建议直接删旧规则重写，而应分步迭代，避免误拦真实流量。
识别哪些白名单条目已过时
过时规则通常表现为：合作方域名下线、子域名弃用、测试域名（如 localhost、127.0.0.1、staging.example.com）残留、或硬编码的 IP 地址长期未更新。可结合以下方式排查：
- 查 Nginx 访问日志：用
grep "403" /var/log/nginx/access.log | awk '{print $1,$12}' | sort | uniq -c | sort -nr统计被拒 Referer，看是否有大量来自已停用域名的请求 - 检查配置中明显陈旧的条目：如
example-old.com、beta.yourdomain.net、192.168.1.100等未在当前业务中使用的地址 - 对比当前
server_name和实际部署的子域名列表，剔除未在 DNS 或 CDN 中解析的域名
重构白名单结构，提升可维护性
旧配置常把所有域名堆在一行，难以阅读和审计。推荐按用途分组、显式注释，并统一使用安全匹配方式：
- 主域与子域分开写明，避免依赖
*.example.com（它不包含example.com）；正确写法：example.com www.example.com ~\.<strong>example\.com$</strong> - 合作方域名单独成行并加注释，例如：
# partner: marketing-tool.trusted.co - 本地/开发环境条目集中管理，如：
localhost 127.0.0.1 ~\.(local|test)$，避免混入生产配置 - 用正则锚定结尾并转义点号（
\.），防止误匹配，例如~\.baidu\.(com|cn)$比baidu更精准
确保基础访问不被误伤
重构后最常出问题的是合法空 Referer 被拦截。必须保留且显式声明以下两类：
-
none：用户直接输入图片 URL、书签访问、HTTPS 页面跳转到 HTTP 资源等场景 -
blocked：隐私插件、企业代理、部分 App 内浏览器会清空或篡改 Referer，值存在但不以http://或https://开头
漏掉任一者，都可能导致后台编辑器预览图、微信内嵌页、邮件图文链接等正常场景失效。
验证与灰度上线
不要全量 reload 后就认为完成。建议：
- 用
curl -H "Referer: https://example.com/page" https://yoursite.com/img/test.jpg测试白名单域名 - 用
curl -H "Referer:" https://yoursite.com/img/test.jpg测试空 Referer（应放行） - 用
curl -H "Referer: https://bad-site.com" ...测试非法来源（应返回 403 或 444） - 上线前先在非主 server 块或测试子域名中启用新规则，观察 24 小时日志无异常后再同步至正式配置
