配置图片防盗链的香港云服务器，如何结合访客地区与运营商选择线路？

同一张图片在官网页面中显示正常，但部分地区打开缓慢，或者直接访问图片地址时返回 403，这两个现象不一定由同一个问题引起。前者通常要从域名入口、访客地区、运营商以及去程和回程路径判断；后者则要检查图片防盗链规则是否按预期生效。

图片防盗链功能在香港云服务器怎么配置？正确顺序是：先根据目标访客地区和运营商选择并验收图片域名的接入线路，再在实际处理图片请求的入口配置来源校验，最后用相同图片、相同域名和相同请求条件验证合法访问、非法引用、无来源请求以及完整下载表现。防盗链返回的 403 只能说明来源校验拒绝了请求，不能作为线路质量的判断依据。

一、先明确线路和防盗链各自的验收标准

线路解决的是“访客如何到达图片入口”，防盗链解决的是“请求到达后是否允许读取图片”。如果图片域名经过缓存或内容分发层，实际链路可能是：

访客网络 → 图片域名入口或缓存层 → 香港云服务器源站 → 图片文件

因此，不能只在香港云服务器内部访问图片，也不能只检查源站 Nginx。源站内部访问成功，只能证明服务器本身能够返回图片，无法证明中国大陆不同地区、不同运营商或香港本地网络访问该入口时表现正常。

线路验收至少应同时关注：

• 域名解析到的入口是否符合当前线路安排。
• TCP 连接是否能够稳定建立。
• 首字节响应时间在多次请求中是否出现明显波动。
• 图片能否完整下载，是否中途中断、超时或明显变慢。
• 去程连接和回程返回是否都正常。
• 切换线路后，请求是否仍然能够到达预期的缓存层或源站。

防盗链验收则应单独判断：

• 允许页面引用图片时是否返回 200。
• 不在允许列表中的外部来源是否返回 403。
• 没有 Referer 时的结果是否符合业务策略。
• 缓存层是否执行了相同的防盗链判断。
• 合法请求和非法请求是否被错误地共用同一个缓存结果。

二、变更前准备：确认图片入口、线路和回滚点

在修改线路或 Nginx 配置前，先记录当前状态。至少确认以下内容：

• 图片访问域名，例如 img.example.com。
• 图片域名最终指向的是香港云服务器、接入层还是缓存节点。
• 实际需要保护的目录和文件类型，例如 jpg、png、webp、svg 或 avif。
• 允许引用图片的页面域名，例如 example.com 和 www.example.com。
• 当前域名解析结果、接入入口和线路安排。
• 图片是否经过缓存、反向代理或其他上游服务。
• 是否能够使用中国大陆不同地区、主要运营商以及香港本地网络进行测试。
• 当前 Nginx 配置文件位置和服务管理方式。

先导出完整的 Nginx 配置，便于确认真正生效的 server 和 location：

sudo nginx -T > /tmp/nginx-config-before.txt 2>&1
sudo nginx -T | less

确认实际配置文件后再备份。下面路径只是示例，必须替换为服务器上的真实文件，并确保备份文件不会覆盖上一份有效备份：

sudo cp -a /etc/nginx/conf.d/site.conf /etc/nginx/conf.d/site.conf.bak

如果图片域名前面存在缓存或内容分发层，应先确定防盗链规则部署在哪里。若缓存节点在请求到达源站前直接返回图片，只在源站 Nginx 中配置规则，可能无法拦截全部外部引用。此时需要在缓存层同步校验，或者确认缓存会依据防盗链结果处理请求，并且不会把一次合法请求得到的 200 响应直接提供给非法请求。

三、按访客地区和运营商选择接入线路

1. 先按真实访客分布确定测试范围

线路选择不应从线路名称或单个测试地点开始，而应从实际访客来源开始。可以从访问日志、网站统计或现有接入服务报告中整理出地区和运营商分布。

表中的地区和运营商需要替换成真实访客数据。单个办公地点的测试结果不能代表全部用户；即使是同一个运营商，不同地区到香港入口的路径也可能不同。

2. 同时观察去程、回程和完整下载

访客发起连接时，能够反映其到达入口的去程表现；服务器返回图片内容时，则会体现回程、出口拥塞、缓存命中和源站响应等情况。只测试 ping、只查看路由跳数，或者只观察连接建立，都不能代替真实图片下载。

在每个目标地区和运营商网络中，使用相同的：

• 图片域名；
• 图片路径；
• 图片文件；
• 来源页面；
• 请求时间段；
• 请求命令和参数。

然后记录解析结果、连接建立、首字节、完整下载、状态码和图片大小。若连接建立很快，但完整下载明显变慢，问题更可能出现在回程、出口拥塞、缓存未命中或源站返回过程，而不是 valid_referers 判断本身。若连接阶段就频繁超时，则应优先检查入口线路、运营商覆盖和安全策略，不要反复修改防盗链规则。

3. 向线路提供方核对可交付内容

没有当前、可追溯的线路资料时，不要自行补充线路归属、覆盖范围、延迟、带宽或稳定性数字。变更前应让线路提供方明确说明：

1. 入口面向哪些地区和运营商，是否所有访客使用同一入口。
2. 去程和回程是否采用相同的优化方式。
3. 是否能够按地区或运营商使用不同入口。
4. 切换线路后，公网地址、域名解析和安全策略是否需要同步调整。
5. 线路异常时是否存在可执行的回退入口。
6. 费用按照入口数量、带宽、流量、回源或其他什么维度计算。
7. 修改解析或接入入口后，如何判断变更已经生效。

如果对方只提供一个固定入口，就不能在 Nginx 中“伪造”按运营商选线。Nginx 可以校验请求、记录访问并返回图片，但通常不能准确替代接入层完成运营商识别和跨运营商线路调度。

四、在实际图片入口配置防盗链

1. 按实际 location 合并规则

不要直接覆盖整份 Nginx 配置。先通过 nginx -T 找出处理图片域名和图片路径的真实 server、location。如果已有正则位置、反向代理或缓存规则，应在原有逻辑上合并防盗链条件，避免新增一个实际上不会被匹配到的规则。

如果图片由 Nginx 直接处理，可以使用以下示例。域名、路径和文件扩展名必须替换为实际值：

location ~* \.(?:jpg|jpeg|png|gif|webp|svg|avif)$ {
    valid_referers none blocked example.com www.example.com;

    if ($invalid_referer) {
        return 403;
    }
}

这段配置的含义是：

• example.com 和 www.example.com 是允许引用图片的页面域名。
• none 表示请求没有携带 Referer 时仍然允许访问。
• blocked 表示请求带有 Referer，但内容不完整或不包含常见协议标识时允许访问。
• 其他来源会被判定为无效引用，并返回 403。

对于公开文章、产品介绍页和普通官网图片，保留 none 通常更重视兼容性。部分浏览器、移动端应用或隐私策略可能不发送 Referer，过于严格的规则会把正常访问误判为盗链。

如果业务明确要求没有来源信息的请求也必须拒绝，可以移除 none：

location ~* \.(?:jpg|jpeg|png|gif|webp|svg|avif)$ {
    valid_referers blocked example.com www.example.com;

    if ($invalid_referer) {
        return 403;
    }
}

移除 none 后，直接输入图片地址、某些应用内页面以及不发送 Referer 的正常请求，都可能返回 403。这不是线路故障，而是更严格的来源策略，必须先确认业务能够接受。

2. 图片在目录位置中处理时，直接合并判断

如果现有配置是按目录处理图片，例如：

location /images/ {
    root /var/www/site;
}

可以将防盗链判断合并到该位置：

location /images/ {
    root /var/www/site;

    valid_referers none blocked example.com www.example.com;

    if ($invalid_referer) {
        return 403;
    }
}

这里的 /images/、root 路径和允许域名都只是示例。实际配置中应以 nginx -T 显示的生效路径为准，并确认没有其他 location 优先处理相同请求。

如果图片由上游服务返回，应把来源判断放在真正接收图片请求的入口，并确认上游不会绕过该入口。若图片由缓存层直接返回，则还要在缓存层设置相同的判断逻辑，或者确认缓存不会忽略 Referer、不会让合法请求的缓存结果被非法请求复用。

3. 明确防盗链的适用边界

防盗链使用的是 Referer 请求头，适合减少普通外站嵌入和带宽滥用，但不等同于身份认证。Referer 可能缺失，也可能被非浏览器请求伪造。

涉及付费图片、用户隐私图片或明确访问权限的内容时，不能只依赖 valid_referers。应改用带有效期和校验机制的图片地址，或配合已有的访问授权机制。线路选择和来源校验也不能替代文件权限控制。

4. 检查语法后再重载

配置修改完成后，先检查语法：

sudo nginx -t

只有检查成功后，才执行平滑重载：

sudo systemctl reload nginx

如果服务器不是由 systemd 管理 Nginx，应先确认服务管理方式，再使用对应的重载命令。不要在 nginx -t 未通过时直接重启服务。重载影响的是当前 Nginx 配置，线路和域名解析不会因此自动改变。

五、用同一套请求同时验收线路和防盗链

1. 先确认当前域名入口

在测试设备或测试主机上执行：

getent ahosts img.example.com

如果系统安装了 dig，也可以执行：

dig +short img.example.com

记录测试时间、解析结果、访客地区和运营商。修改线路或域名解析后，不要只依据一台设备的即时结果判断切换成功，应在实际缓存和解析更新后再次核对。

2. 验证合法页面引用

从目标访客网络发起带合法来源的请求：

curl -sS -o /dev/null \
  -D /tmp/image-valid.headers \
  -e "https://www.example.com/article/1" \
  -w 'status=%{http_code} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total} size=%{size_download}\n' \
  "https://img.example.com/images/demo.jpg"

正常情况下应同时满足：

• 状态码为 200；
• 返回内容大小不为零；
• 图片能够完整下载；
• connect、ttfb 和 total 多次请求没有明显异常；
• 页面实际能够显示图片；
• Nginx 或接入层日志能够找到对应请求。

同一命令应分别在目标地区、主要运营商和香港本地网络执行。只有相同图片、相同域名和相同来源条件下的结果，才适合用于比较线路差异。

3. 验证外部来源是否被拒绝

使用不在允许列表中的来源域名：

curl -sS -o /dev/null \
  -D /tmp/image-invalid.headers \
  -e "https://other.example/article/1" \
  -w 'status=%{http_code} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  "https://img.example.com/images/demo.jpg"

预期结果是 403。如果仍然返回 200，按以下顺序检查：

1. 请求是否确实访问了目标图片域名和路径。
2. 图片路径是否被其他 location 优先处理。
3. 修改后的配置是否通过 nginx -t 并完成重载。
4. 图片是否由前置缓存直接返回，导致请求没有到达 Nginx。
5. 缓存层是否忽略了来源校验，或复用了合法请求的缓存结果。
6. 是否存在其他允许来源规则覆盖了当前判断。

4. 验证无来源请求

如果配置保留了 none，执行：

curl -sS -o /dev/null \
  -H 'Referer:' \
  -w 'status=%{http_code} total=%{time_total}\n' \
  "https://img.example.com/images/demo.jpg"

预期结果通常为 200。如果已经移除 none，则应预期返回 403。这个结果必须与业务策略一致，不能单纯把 403 认定为配置成功或失败。

5. 通过完整下载判断线路表现

对完整图片执行下载测试：

curl -sS \
  -o /tmp/image-line-test.jpg \
  -w 'status=%{http_code} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total} size=%{size_download}\n' \
  "https://img.example.com/images/demo.jpg"

如果连接建立快、首字节正常，但完整下载耗时明显增加，应继续检查回程、出口拥塞、缓存未命中或源站返回过程。如果连接阶段就频繁超时，则优先检查入口线路、运营商覆盖、解析结果和安全策略。

traceroute 或其他路由探测命令只能作为辅助证据，不能单独证明图片业务质量：

command -v traceroute && traceroute -n img.example.com

线路最终应以实际 HTTP 请求、完整图片下载和多运营商重复测试为准。路由跳数变化本身不等于图片访问一定变好或变差。

六、按现象由外到内排查，必要时执行回滚

如果新规则导致正常图片大面积无法访问，应先停止继续修改，恢复变更前的 Nginx 配置：

sudo cp -a /etc/nginx/conf.d/site.conf.bak /etc/nginx/conf.d/site.conf
sudo nginx -t
sudo systemctl reload nginx

执行回滚前要确认备份文件确实对应本次修改前的版本。nginx -t 通过后才能重载；如果检查失败，应保留输出并继续修复，不要强行重启。

这组操作只回滚 Nginx 防盗链规则，不会自动恢复已经修改的域名解析、缓存层规则或接入线路。如果线路也发生过变化，还要根据变更记录恢复原入口，并重新验证合法图片访问和完整下载。

七、保留证据，避免下一次切线后重复误判

每次线路或防盗链变更，至少保留以下证据：

• 测试时间和访客地区；
• 运营商和测试网络；
• 图片域名、图片路径和来源页面；
• 域名解析结果；
• 合法、非法和无来源请求的状态码；
• connect、ttfb、total 和图片大小；
• nginx -t 的检查结果；
• 接入层或源站日志中的对应请求；
• 变更前后的线路入口信息；
• 缓存层是否命中，以及是否实际执行来源校验。

完成验收后，至少保留一次跨地区、跨运营商的合法访问结果，以及一次非法来源返回 403 的结果。后续发生线路调整、缓存策略变化、图片域名变化或允许引用的页面域名变化时，应重新核对入口、location 匹配和缓存行为，避免线路已经切换成功，但防盗链规则仍然沿用旧域名或旧缓存配置。