![[图2，EdgeOne 昨日 L7 访问流量，显示 6.56 GB]](https://media.shuijingwanwq.com/2026/07/2-20-1024x480.png)
![[图4：EdgeOne 按 URL path 开始于 /en/ 筛选后的流量截图]](https://media.shuijingwanwq.com/2026/07/4-24-1024x664.png)
![[图3：执行核心升级时返回 524 No Reason Phrase]](https://media.shuijingwanwq.com/2026/07/3-28-1024x500.png)
最近在检查网站 GA4 数据时，我发现了一个一直让我感觉不太正常的现象：
网站首页的浏览次数明显偏高，而且整体用户互动时长又非常短。
一开始我并没有想到问题会出在 CDN 的 Query String 处理规则上。直到这次从百度搜索结果实际点击进入网站，才终于把整个问题串了起来。
一、GA4 首页浏览次数异常偏高
最近 30 天的 GA4 报告中，网站共有约：
- 9 万活跃用户；
- 8.6 万新用户；
- 9.2 万浏览次数；
- 每位活跃用户平均互动时长只有 9 秒。
在热门网页中，首页标题：
永夜 – 没有不值得去解决的问题，也没有不值得去学习的技术！
竟然有 3136 次浏览。
这个数字之前我就觉得有点奇怪。
因为从网站实际内容结构和流量来源来看，用户更多应该是通过搜索引擎直接进入具体文章，而不是大量进入首页。
与此同时，首页这一行的跳出率达到了 78.4%。
当时还不能确定原因，只能先怀疑是不是统计方式或者某些异常访问导致的。
二、从百度点击一条搜索结果后，发现了真正的问题
我在百度搜索：
A Tour of Go百度返回了我博客中的一条历史搜索结果。
奇怪的是，搜索结果摘要明显还是一篇与 A Tour of Go 有关的文章内容，但搜索结果标题却已经变成了我的网站首页标题。
更关键的是，点击这个搜索结果以后，浏览器地址栏显示的是：
https://www.shuijingwanwq.com/?p=15623但实际打开的却是网站首页。
/?p=15623，实际显示首页】这就明显不正常了。
WordPress 本身支持：
?p=文章ID这种访问形式。
即使网站现在使用的是：
/年/月/日/ID/形式的固定链接，?p=ID 仍然是 WordPress 可以识别的查询方式。
对于一个当前有效的文章 ID，WordPress / Polylang 会正常将它重定向到正式 permalink。
问题就在于：为什么浏览器仍然停留在 /?p=15623，服务器却返回了首页？
三、问题最终定位到 EdgeOne 的 Query String 归一化规则
为了提高缓存命中率、减少大量带无意义查询参数的 URL 产生缓存碎片，我之前在 EdgeOne 中配置过一条规则：
www 文章与公开列表页 Query String 归一化
这条规则会对首页、分类页、标签页、日期归档页等公开页面进行 Query String 归一化。
原来的规则已经专门排除了：
s
preview
preview_id
preview_nonce这些具有实际功能的参数。
但这里遗漏了两个很重要的 WordPress 参数：
p
page_id而规则下面又配置了：
自定义 Cache Key
查询字符串：全部忽略以及：
回源请求参数设置
查询字符串：全部忽略于是当用户访问：
/?p=15623时，URL path 实际仍然是：
/同时它又满足：
s 不存在
preview 不存在
preview_id 不存在
preview_nonce 不存在所以成功命中了这条归一化规则。
最终请求链路相当于变成了：
用户请求：
/?p=15623
↓
EdgeOne 忽略 Query String
↓
回源：
/
↓
WordPress 返回首页
↓
客户端得到：
HTTP 200 + 首页 HTML这就解释了为什么：
浏览器地址仍然是 /?p=15623但页面显示的却是首页。
四、源站测试进一步确认问题
为了排除 WordPress 自身的问题，我绕过 CDN，直接访问源站进行了测试。
对于：
/?p=15623源站直接返回：
HTTP/2 404而经过 EdgeOne 时，修复之前却返回：
HTTP/2 200并且页面中：
<link rel="canonical" href="https://www.shuijingwanwq.com/" />标题也是首页标题。
这说明 EdgeOne 在回源以前就已经把：
p=15623丢掉了。
为了进一步确认 WordPress 的 ?p= 机制本身没有问题，我又找了一篇确定存在的文章：
https://www.shuijingwanwq.com/2026/09/04/27389/直接绕过 CDN 请求：
https://www.shuijingwanwq.com/?p=27389源站正常返回：
HTTP/2 301
location: https://www.shuijingwanwq.com/2026/09/04/27389/
x-redirect-by: Polylang因此可以确认：
WordPress / Polylang 对
?p=ID的兼容本身完全正常，问题出在 CDN 对 Query String 的处理。
五、修复：给 p 和 page_id 增加保护
这次并没有推翻原来的 CDN 缓存策略。
因为对大量公开列表页来说，忽略纯追踪参数依然能够有效减少缓存碎片。
我采取的是一个最小修复：
在原来的条件中继续增加：
p 不存在
page_id 不存在
p 和 page_id 不存在条件】也就是说：
普通的：
/?utm_source=xxx仍然可以进入 Query String 归一化。
但是：
/?p=27389因为存在 p 参数，就不会再进入“查询字符串全部忽略”的规则。
这样 EdgeOne 会把完整请求交给 WordPress。
六、修复后，有效 ?p= 已恢复正常 301
发布新规则后，再次经过 EdgeOne 请求：
https://www.shuijingwanwq.com/?p=27389返回：
HTTP/2 301
x-redirect-by: Polylang
location:
https://www.shuijingwanwq.com/2026/09/04/27389/
eo-cache-status: MISS
/?p=27389 正常 301】这说明 EdgeOne 已经不再吞掉 p 参数。
正确链路恢复成：
/?p=27389
↓
EdgeOne 保留 p
↓
WordPress / Polylang
↓
301
↓
/2026/09/04/27389/七、无效 ?p= 也恢复成真正的 404
之前百度中的：
/?p=15623修复以后再次请求：
HTTP/2 404
eo-cache-status: MISS
/?p=15623 返回 404】这同样是正确行为。
此前真正的问题并不是这个 URL 应不应该 404，而是：
一个本来应该返回 404 的 URL，被 CDN 错误转换成了首页，并返回 HTTP 200。
从 SEO 角度来看，这种情况甚至比正常 404 更麻烦。
搜索引擎看到的是：
URL：
/?p=15623
HTTP：
200
canonical：
/
title：
首页标题很容易造成 URL、标题、正文内容和 canonical 之间的混乱。
百度搜索结果中出现：
文章摘要 + 首页标题
很可能就与这种长期错误响应有关。
至于百度是什么时候发现并保存了 ?p=15623 这个历史 URL，目前已经很难准确追溯。
但无论这个 URL 来自哪里，CDN 都不应该擅自删除具有 WordPress 路由语义的 p 参数。
八、GA4 数据证明这不是一个小概率问题
修复以后，我又回到 GA4，直接搜索：
?p=结果让我有些意外。
过去 30 天：
?p=相关页面浏览次数达到 2479 次。
而且 GA4 中一共出现了约：
1856 个不同的
?p=URL。
?p= 共有 2479 次浏览】而前面首页标题的浏览次数是：
31362479 已经相当于 3136 的大约：
79%当然，不能简单地认为：
3136 - 2479 = 657就是首页真实浏览次数。
因为这些访问发生的具体时间、CDN 缓存状态、规则生效时间并不完全一致。
但这个数据至少说明了一件事情：
之前首页浏览次数异常偏高，极有可能有很大一部分就是这些
?p=请求被错误返回首页造成的。
九、这也解释了为什么用户互动时长会这么短
GA4 中所有 ?p= URL 合计的平均互动时长只有：
3 秒
很多具体 URL 甚至只有：
0 秒
2 秒
3 秒
4 秒这个现象现在也很好解释了。
用户本来是在百度或者其他搜索引擎中点击一篇具体文章。
用户预期：
搜索结果
↓
具体文章实际却变成：
搜索结果
↓
/?p=xxxx
↓
CDN 删除 p
↓
首页用户点击以后发现内容完全不对，自然很可能几秒钟就离开。
因此，这个问题不仅污染了：
- 首页浏览次数；
- 页面标题统计；
- 跳出率；
- 平均互动时长；
还真实影响了：
- 搜索用户体验；
- 文章实际访问量；
- 搜索引擎对 URL 的判断；
- 网站整体行为数据的可信度。
这可能也是最近一段时间 GA4 中平均互动时长只有几秒的重要原因之一。
十、英文站 Cloudflare 也同步修复
我的中文主站：
www.shuijingwanwq.com目前使用 EdgeOne。
英文站：
en.shuijingwanwq.com使用 Cloudflare。
英文站也存在类似的 Query String 归一化规则，因此这次同步增加了：
p
page_id保护。
测试有效文章：
/?p=27398结果：
HTTP/2 301
location:
https://en.shuijingwanwq.com/2026/09/04/27398/测试不存在的文章：
/?p=999999999结果：
HTTP/2 404因此两边 CDN 的行为已经重新与源站保持一致。
十一、没有继续盲目扩大规则修改范围
发现 p 问题以后，我也检查了一些其他可能具有功能语义的 Query String，例如：
page
paged
cpage
feed
embed
rest_route
lang最近 30 天中：
paged= 0
cpage= 0
feed= 0
embed= 0
rest_route= 0
lang= 0page= 搜索到了 94 次，但进一步检查发现主要是类似：
query-62-page=4这样的参数。
我又直接绕过 CDN，对：
/page/31/和：
/page/31/?query-62-page=4进行了实际页面内容比较。
虽然完整 HTML 的 hash 不完全相同，但页面中的文章链接列表完全一致。
所以目前没有证据证明它造成了类似 p 的实际问题。
最终我决定：
只修已经有真实访问数据和实测证据的问题，不因为理论风险一次性大幅增加 CDN 规则复杂度。
目前继续保护：
s
preview
preview_id
preview_nonce
p
page_id其他参数暂时继续观察。
总结
这次问题表面上看只是：
首页浏览次数为什么这么高？
但最终排查下来，实际上是一条完整的 CDN、WordPress、搜索引擎和 GA4 联动问题：
百度历史 ?p= URL
↓
EdgeOne Query String 归一化
↓
p 参数被删除
↓
源站收到 /
↓
返回首页 HTTP 200
↓
用户看到错误页面
↓
GA4 page_location 仍是 ?p=
↓
page_title 却变成首页标题
↓
首页浏览量被放大
↓
互动时长、跳出率同时恶化真正的问题并不是“使用 Query String 归一化”本身。
CDN 忽略诸如 UTM 一类不会改变页面内容的参数，确实有利于提高缓存命中率。
问题在于：
不能把会改变 WordPress 路由和页面内容的参数，当成普通追踪参数一起过滤。
这次遗漏的是：
p
page_id而且从 GA4 数据来看，过去 30 天 ?p= 就产生了 2479 次浏览。
如果只是看 CDN 配置本身，这两个参数很容易被忽略。
但最终真正把问题暴露出来的，却是一次很普通的操作：
从百度搜索结果点击进入网站。
有时候，真实用户访问链路确实比单纯看监控和配置更容易发现问题。
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