![[图2，EdgeOne 昨日 L7 访问流量，显示 6.56 GB]](https://media.shuijingwanwq.com/2026/07/2-20.png)
最近我在腾讯云 EdgeOne 控制台里发现一个比较明显的问题：站点刚接入 EdgeOne 不久，套餐里的安全加速流量消耗速度就明显偏快。
我当前使用的是 EdgeOne 个人版套餐，套餐内安全加速流量为 50 GB。实际查看时，已经使用了 16.55 GB / 50 GB。如果按照当时的消耗速度继续下去，这个套餐很可能撑不到一个月。
所以这次没有继续盲目升级套餐，而是先做了一次流量分析，然后把 WordPress 的 /wp-content/uploads/ 静态资源迁移到一个单独的 media.shuijingwanwq.com 子域名，并通过 Cloudflare 承接这部分媒体资源流量。
这篇文章记录一下完整排查与调整过程。
![[图1，EdgeOne 套餐管理页面，显示安全加速流量已使用 16.55 GB / 50 GB]](https://media.shuijingwanwq.com/2026/07/1-21-1024x394.png)
一、先确认 EdgeOne 的流量消耗情况
我先进入 EdgeOne 的套餐管理页面查看当前套餐用量。
当时看到的数据大概是：
安全加速流量：16.55 GB / 50 GB
安全加速请求：33.71 万次 / 300 万次
这个数据已经让我比较警惕。因为如果一天消耗 5 GB 左右，那么 50 GB 流量很快就会用完。
接着我进入 EdgeOne 的指标分析页面，查看昨天和今天的 L7 访问流量。
昨天的数据大致如下：
L7 访问流量：6.56 GB
EdgeOne 响应流量：6.41 GB
客户端请求流量：145.83 MB
L7 访问请求数：18.32 万次
从国家/地区看，中国大陆和美国是主要来源：
中国大陆境内：3.57 GB
美国：2.22 GB
![[图2，EdgeOne 昨日 L7 访问流量，显示 6.56 GB]](https://media.shuijingwanwq.com/2026/07/2-20-1024x480.png)
这里可以先得出一个判断：这不是一个非常明显的单 IP 攻击。因为在 IP 排行里，Top IP 的占比并不高，没有出现某个 IP 独占大量流量的情况。
二、继续看缓存状态：MISS 比例偏高
接着我切到缓存状态维度看数据。
昨天的缓存状态大致是：
MISS：4.31 GB
HIT：2.03 GB
dynamic：70.72 MB
今天早上的缓存状态也类似：
MISS：1.15 GB
HIT：514.4 MB
dynamic：10.59 MB
![[图3，EdgeOne 缓存状态分析，显示 MISS 4.31 GB、HIT 2.03 GB]](https://media.shuijingwanwq.com/2026/07/3-19-1024x480.png)
这个数据说明，EdgeOne 的缓存命中并不理想。大量流量仍然是 MISS 状态。
不过这里也要注意一个点：提高 HIT 率并不一定等于直接降低 EdgeOne 套餐流量。因为即使资源在 EdgeOne 节点 HIT，只要 EdgeOne 把资源返回给用户，仍然会消耗 EdgeOne 的安全加速流量。
所以我后面真正的优化方向不是单纯提高 EdgeOne 缓存，而是把高流量的 /wp-content/uploads/ 媒体资源迁移到 Cloudflare 的子域名上，让 EdgeOne 不再直接承接这些图片和附件的传输。
三、发现真正的大头：uploads 目录和 logo.png
在 URL Path 排行里，我发现一个非常明显的资源：
/wp-content/uploads/2026/05/logo.png 530.22 MB
今天早上这个文件也已经消耗了：
/wp-content/uploads/2026/05/logo.png 143.07 MB
![[图4，URL Path 排行，显示 logo.png 昨日消耗 530.22 MB]](https://media.shuijingwanwq.com/2026/07/4-19-1024x480.png)
这张 logo.png 原本同时用于 Site Logo 和站点图标，尺寸是：
1024 × 1024
文件大小是：
884 KB
由于它作为 Site Logo 会在很多页面中出现，所以文件过大时，很容易成为高频消耗资源。
于是我先在 WordPress 后台把这张图片缩放到：
512 × 512
压缩后大小变成：
173 KB
相当于从 884 KB 降到了 173 KB，单文件体积减少了大约 80%。
![[图5，WordPress 站点标识页面，Site Logo 与站点图标使用同一张图片]](https://media.shuijingwanwq.com/2026/07/5-15.png)
![[图6，WordPress 图片编辑页面，将 1024×1024 缩放为 512×512]](https://media.shuijingwanwq.com/2026/07/6-13-1024x802.png)
压缩 Logo 是一个必要动作，但它只能降低单个资源的体积，不能从根本上解决 EdgeOne 流量消耗的问题。
因为 /wp-content/uploads/ 目录下不只有 Logo，还有大量文章截图、图片、ZIP 附件等资源。
四、确认 uploads 目录里不只是图片，还有大附件
我在服务器上查看了 uploads 目录下体积最大的文件：
find /data/wwwroot/www.shuijingwanwq.com/wp-content/uploads -type f \( -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.png" -o -iname "*.gif" -o -iname "*.pdf" -o -iname "*.zip" \) -printf '%s %p\n' | sort -nr | head -n 10
结果发现 uploads 目录里有不少大文件，例如：
113223692 /data/wwwroot/www.shuijingwanwq.com/wp-content/uploads/2026/05/com.termux_1002.zip
49688068 /data/wwwroot/www.shuijingwanwq.com/wp-content/uploads/2026/05/FlClash-0.8.93-android-arm64-v8a.zip
7639822 /data/wwwroot/www.shuijingwanwq.com/wp-content/uploads/2026/04/com.wireguard.android-1.0.20260315.zip
6456103 /data/wwwroot/www.shuijingwanwq.com/wp-content/uploads/2025/02/3-1.jpg
这说明 /wp-content/uploads/ 不能简单理解为图片目录。它本质上是 WordPress 媒体库目录，里面可能包含图片、压缩包、PDF、附件等各种上传文件。
所以我没有使用 img.shuijingwanwq.com，而是选择了更合适的子域名：
media.shuijingwanwq.com
这个命名更适合承接整个 WordPress 媒体库资源。
五、创建 media 子域名，并通过 Cloudflare 承接流量
我先在 Cloudflare DNS 中添加一条记录：
类型：A
名称：media
IPv4 地址：源站服务器 IP
代理状态：已代理，也就是橙色云朵开启
TTL：自动
![[图7，Cloudflare DNS 添加 media.shuijingwanwq.com 记录]](https://media.shuijingwanwq.com/2026/07/7-6.png)
这一步的目标是让：
media.shuijingwanwq.com
走 Cloudflare，而不是走 EdgeOne。
六、使用 OneinStack 添加 media 虚拟主机
我的服务器是 OneinStack 环境，所以直接使用：
~/oneinstack/vhost.sh
添加虚拟主机。
关键配置如下：
域名：media.shuijingwanwq.com
网站目录：/data/wwwroot/www.shuijingwanwq.com/wp-content/uploads
SSL：Let's Encrypt
HTTP 自动跳转 HTTPS：开启
Rewrite：不启用
Hotlink Protection：不启用
![[图8，OneinStack 添加 media.shuijingwanwq.com 虚拟主机成功]](https://media.shuijingwanwq.com/2026/07/8-5-1024x573.png)
这里有一个关键点：media.shuijingwanwq.com 的网站目录不是 WordPress 根目录，而是直接指向 uploads 目录：
/data/wwwroot/www.shuijingwanwq.com/wp-content/uploads
这样原来的资源：
https://www.shuijingwanwq.com/wp-content/uploads/2026/05/logo-e1783470913383.png
就可以通过新的 media 域名访问为：
https://media.shuijingwanwq.com/2026/05/logo-e1783470913383.png
URL 更短，也更符合媒体资源子域名的定位。
七、media 虚拟主机必须禁止执行 PHP
OneinStack 默认生成的 Nginx 虚拟主机配置中，可能会包含 PHP 执行规则。
但是 media.shuijingwanwq.com 的根目录是 uploads。uploads 目录只应该作为静态资源目录，不能执行 PHP。
所以我修改了：
/usr/local/nginx/conf/vhost/media.shuijingwanwq.com.conf
把：
index index.html index.htm index.php;
改成：
index index.html index.htm;
并把 PHP 处理规则改成直接返回 403：
location ~ [^/]\.php(/|$) {
return 403;
}
然后测试并重载 Nginx：
nginx -t && nginx -s reload
![[图9，media 虚拟主机配置，禁止执行 PHP]](https://media.shuijingwanwq.com/2026/07/9-4.png)
之后我测试：
curl -I https://media.shuijingwanwq.com/test.php
返回：
HTTP/2 403
server: cloudflare
cf-cache-status: BYPASS
说明 media 子域名不会执行 PHP，这一点很重要。
八、验证 media 资源是否能被 Cloudflare 缓存
我先测试 Logo：
curl -I https://media.shuijingwanwq.com/2026/05/logo-e1783470913383.png
第一次可能是：
cf-cache-status: MISS
再次请求后变成：
cf-cache-status: HIT
返回头里可以看到：
server: cloudflare
content-type: image/png
content-length: 172972
cache-control: max-age=2592000
cf-cache-status: HIT
接着我又测试一个比较大的 ZIP 文件：
curl -I https://media.shuijingwanwq.com/2026/05/com.termux_1002.zip
第二次请求后也能看到：
cf-cache-status: HIT
content-length: 113223692
这说明 Cloudflare 可以正常承接 media 子域名下的图片和大附件。
九、修改 WordPress 上传资源 URL
接下来需要让 WordPress 自己输出 media.shuijingwanwq.com，而不是继续输出：
https://www.shuijingwanwq.com/wp-content/uploads
我的服务器上没有安装 wp-cli，所以用 PHP 直接调用 WordPress 环境来检查配置：
cd /data/wwwroot/www.shuijingwanwq.com && php -r 'require "wp-load.php"; echo get_option("upload_url_path") . PHP_EOL;'
结果为空，说明之前没有单独设置上传 URL。
然后执行：
cd /data/wwwroot/www.shuijingwanwq.com && php -r 'require "wp-load.php"; update_option("upload_url_path", "https://media.shuijingwanwq.com"); echo get_option("upload_url_path") . PHP_EOL;'
输出：
https://media.shuijingwanwq.com
![[图10，使用 PHP 设置 WordPress upload_url_path 为 media 域名]](https://media.shuijingwanwq.com/2026/07/10-5-1024x77.png)
继续验证 WordPress 内部上传目录：
cd /data/wwwroot/www.shuijingwanwq.com && php -r 'require "wp-load.php"; $u = wp_upload_dir(); echo $u["baseurl"] . PHP_EOL;'
输出：
https://media.shuijingwanwq.com
说明 WordPress 内部上传 URL 已经切换成功。
十、清理 W3 Total Cache 页面缓存
设置 WordPress 上传 URL 后，前台页面不一定马上变化。因为页面 HTML 可能被 W3 Total Cache 或 EdgeOne 缓存。
我先绕过缓存测试：
curl -s 'https://www.shuijingwanwq.com/?media_test=1' | grep -oE 'https://media\.shuijingwanwq\.com/[^"]+|/wp-content/uploads/[^"]+'
这时可以看到页面里已经输出：
https://media.shuijingwanwq.com/2026/05/logo-150x150.png
https://media.shuijingwanwq.com/2026/07/1-20-245x300.png
https://media.shuijingwanwq.com/2026/07/2-18-300x230.png
...
说明 WordPress 动态输出已经是 media 域名。
然后在 WordPress 后台清理 W3 Total Cache：
Performance → Purge All Caches
再次测试首页：
curl -s https://www.shuijingwanwq.com/ | grep -oE 'https://media\.shuijingwanwq\.com/[^"]+|/wp-content/uploads/[^"]+'
结果里已经全部变成：
https://media.shuijingwanwq.com/...
![[图11，首页源码中图片 URL 已经切换为 media.shuijingwanwq.com]](https://media.shuijingwanwq.com/2026/07/11-3-1024x403.png)
十一、在 EdgeOne 中做 uploads 全量 301 跳转
虽然 WordPress 新输出已经切到 media 域名，但历史缓存页面、搜索引擎、外部引用、旧文章中仍然可能访问旧地址：
https://www.shuijingwanwq.com/wp-content/uploads/2026/07/1-20-245x300.png
如果不处理，这些旧地址仍然可能走 EdgeOne。
所以我在 EdgeOne 规则引擎中添加一条全量 uploads 301 规则。
规则名称：
全量 uploads 301
匹配条件：
URL path 正则匹配：
^/wp-content/uploads/(.*)$
执行动作：
访问 URL 重定向
目标请求协议：HTTPS
目标 Hostname：media.shuijingwanwq.com
目标路径：正则替换
正则表达式：^/wp-content/uploads/(.*)$
替换为：/$1
携带查询参数：开启
状态码：301
![[图12，EdgeOne 全量 uploads 301 规则配置]](https://media.shuijingwanwq.com/2026/07/12-4-1024x179.png)
这个规则的作用是把：
https://www.shuijingwanwq.com/wp-content/uploads/2026/07/1-20-245x300.png
跳转为：
https://media.shuijingwanwq.com/2026/07/1-20-245x300.png
注意，静态资源长期缓存规则我暂时没有删除，而是保留作为兜底。因为 EdgeOne 规则部署比较慢，当前没有必要为了删除一条暂时无害的缓存规则，再触发一次部署。
![[图13，EdgeOne 规则列表，显示“全量 uploads 301”规则已启用]](https://media.shuijingwanwq.com/2026/07/13-2-1024x476.png)
十二、验证旧 URL 是否跳转到 media
最后验证旧 URL：
curl -I https://www.shuijingwanwq.com/wp-content/uploads/2026/07/1-20-245x300.png
返回：
HTTP/2 301
location: https://media.shuijingwanwq.com/2026/07/1-20-245x300.png
server: TencentEdgeOne
x-cache-lookup: Return Directly
继续跟随跳转验证完整链路：
curl -IL https://www.shuijingwanwq.com/wp-content/uploads/2026/07/1-20-245x300.png
结果第一段是 EdgeOne 返回 301：
HTTP/2 301
location: https://media.shuijingwanwq.com/2026/07/1-20-245x300.png
server: TencentEdgeOne
第二段是 Cloudflare 返回资源：
HTTP/2 200
server: cloudflare
content-type: image/png
content-length: 21891
cf-cache-status: HIT
cache-control: max-age=2592000
![[图14，curl -IL 验证旧 uploads URL 先经过 EdgeOne 301，再由 Cloudflare 返回 200 HIT]](https://media.shuijingwanwq.com/2026/07/14-3-1024x455.png)
这说明完整链路已经打通：
旧地址：www + /wp-content/uploads/...
→ EdgeOne 301
→ media.shuijingwanwq.com
→ Cloudflare 200
→ cf-cache-status: HIT
十三、这次优化后的结构
调整前：
www.shuijingwanwq.com
└── /wp-content/uploads/
└── 图片、ZIP、附件等资源全部由 EdgeOne 承接
调整后：
www.shuijingwanwq.com
└── HTML 页面仍然走 EdgeOne
media.shuijingwanwq.com
└── WordPress uploads 静态资源走 Cloudflare
旧地址兜底：
www.shuijingwanwq.com/wp-content/uploads/*
→ 301
→ media.shuijingwanwq.com/*
这样一来，EdgeOne 主要负责主站页面、规则、HTML 缓存和安全防护；而图片、截图、ZIP 附件等大体积资源，则交给 Cloudflare 的 media 子域名承接。
十四、为什么没有把整个网站重新迁回 Cloudflare
这次我只是把 WordPress 的 /wp-content/uploads/ 上传资源迁移到 Cloudflare，而不是把整个主站重新迁回 Cloudflare。
原因是：我之前已经测试过，www.shuijingwanwq.com 整站走 Cloudflare 时，中国大陆地区访问体验并不稳定，尤其是移动和联通网络下，页面打开速度会比较慢。这也是我后来从 Cloudflare 迁移到 EdgeOne 的重要原因。
所以这次的思路不是“回到 Cloudflare”，而是做一个折中拆分：
HTML 页面、主站访问、WordPress 动态页面：
继续走 EdgeOne
图片、截图、ZIP、PDF 等上传资源：
迁移到 media.shuijingwanwq.com，通过 Cloudflare 承接这个方案的风险相对可控。因为我的 WordPress 站点已经启用了图片懒加载，页面打开时不会一次性加载所有图片。用户首先请求的仍然是主站 HTML 页面，而这些页面继续由 EdgeOne 提供服务。
也就是说，中国大陆用户访问文章时，首屏体验主要仍然取决于 EdgeOne 和源站缓存；只有当用户滚动到图片位置，浏览器才会去请求 media.shuijingwanwq.com 上的图片资源。
这样做的预期是：
主站首屏速度：尽量保持 EdgeOne 的国内访问优势
图片和附件流量：转移到 Cloudflare，降低 EdgeOne 套餐消耗当然，这不是一个完美方案。中国大陆用户加载文章图片时，仍然可能受到 Cloudflare 在不同运营商网络下访问质量的影响。但相比整站迁回 Cloudflare，这种影响会被图片懒加载削弱很多，也更容易接受。
所以这次优化的核心并不是单纯追求最快访问速度，而是在下面三者之间做平衡：
EdgeOne 成本
中国大陆用户访问体验
WordPress 媒体资源流量压力目前看，把 uploads 媒体资源拆到 Cloudflare，是一个比整站迁移更稳妥的中间方案。
十五、几个经验总结
第一，不要一看到 EdgeOne 流量上涨就马上升级套餐。
这次如果直接升级到更高套餐，成本会明显增加。但实际排查后发现，主要问题集中在 /wp-content/uploads/ 静态资源上，是可以通过架构调整优化的。
第二，Referer 不存在 占比高，不一定就是盗链。
EdgeOne 数据中，Referer 不存在的流量占比很高，但这可能来自浏览器隐私策略、直接访问、爬虫、App 内置浏览器等。如果直接封空 Referer，容易误伤正常用户。
第三，Site Logo 不应该使用过大的图片。
原来的 Logo 是 1024×1024，884 KB。它既用于 Site Logo，也用于站点图标。压缩到 512×512 后，体积降到 173 KB。虽然还不是极致优化，但已经明显降低了单资源消耗。
第四，WordPress 的 uploads 目录不只是图片。
它可能包含图片、ZIP、PDF、附件等各种媒体资源。所以子域名命名为 media.shuijingwanwq.com 比 img.shuijingwanwq.com 更合适。
第五，media 子域名必须禁止执行 PHP。
uploads 目录只应该提供静态资源。如果 media 虚拟主机允许 PHP 执行，一旦有异常 PHP 文件进入 uploads，会带来安全风险。
第六，EdgeOne 规则尽量少频繁调整。
EdgeOne 规则部署可能需要等待较久，所以这次后面尽量减少规则变更。全量 301 生效后，静态资源长期缓存规则暂时保留作为兜底，不急着删除。
十六、后续观察项
这次迁移完成后，接下来我会继续观察 EdgeOne 指标分析里的这些数据：
L7 访问流量
URL Path 排行
/wp-content/uploads/ 是否还出现在高流量排名
状态码 301 占比
EdgeOne 套餐用量增长速度
理想情况下，后续 EdgeOne 的 /wp-content/uploads/ 资源流量会显著下降。即使旧地址仍然被访问，EdgeOne 也只返回很小的 301 响应，不再直接传输图片或 ZIP 文件本体。
这次优化算是一个比较实际的折中方案：不完全迁移 CDN，也不继续升级 EdgeOne 套餐，而是把最消耗流量的 WordPress 媒体资源拆出去，让 EdgeOne 和 Cloudflare 各自承担更适合的部分。
Linux 服务器运维、部署与线上故障排查
如果你的网站或后端服务部署在 Linux 服务器上，遇到访问异常、Nginx 配置问题、MySQL / Redis 异常、Docker 服务不可用、磁盘占满、CPU / 内存过高等问题，可以联系我做一次远程排查。
适合以下场景：
✅ 网站打不开或访问不稳定
✅ Nginx / PHP-FPM 配置异常
✅ MySQL / Redis 性能或连接问题
✅ Docker 服务部署与维护
✅ 服务器迁移与环境配置
✅ CPU / 内存 / 磁盘异常排查
服务内容：
✅ Linux 环境检查
✅ 网站部署与迁移
✅ Nginx / PHP-FPM / MySQL / Redis 排查
✅ Docker 配置与维护
✅ 服务器性能分析
✅ 长期远程运维支持
如需咨询，请联系我，并注明：Linux 运维咨询。
联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com
发表回复