标签： Nginx
-
本文记录一次 WordPress 双 CDN 架构下的 Query String 缓存优化实战。中文站通过 EdgeOne 自定义 Cache Key 与回源请求参数设置，让 canonical 文章 URL 的不同查询参数共用缓存，并在 MISS 回源时删除 Query String；英文站则通过 Cloudflare URL Rewrite Rule 实现相同目标。整个过程结合 HIT/MISS、Age、301、CF-Ray 与 Nginx access log 进行实际验证，最终将规则收敛为仅优化 /YYYY/MM/DD/ID/ 形式的标准文章 URL，在降低随机参数缓存穿透风险的同时保持 CDN 配置简单、清晰、易维护。
-
一次 WordPress 生产站间歇性 502 故障排查记录。阿里云 ECS 一度出现 CPU 100%、Load 超过 9、PHP-FPM Socket 队列达到 510/511，大量请求返回 499 和 502。通过分析 Nginx 日志发现，最近 20000 条请求中有 18455 条携带 Sogou web spider/4.0 User-Agent，并以每分钟约 500～700 次的频率持续遍历网站。随后在 EdgeOne 中通过 *Sogou* User-Agent 规则进行边缘拦截，Sogou UA 请求降至 0，PHP-FPM 队列恢复为 0/511，CPU 空闲率最高恢复到 97%，后台连续请求全部返回 HTTP 200。此次排查说明，服务器出现性能瓶颈时，不应急于升级配置，应先确认异常流量和真正的资源消耗来源。
-
本文记录了将 WordPress 英文站从 `www` 主域名下的 `/en/` 路径迁移到 `en.shuijingwanwq.com` 子域名的完整实践。由于站点原有数千条标签 slug 转换、旧标签合并和专题重定向规则，不能简单使用一条通用 rewrite。最终通过“历史路径映射、最终域名转换、普通 `/en/` 兜底迁移”三层逻辑，实现旧英文标签和专题一次 301 到达最终英文地址，同时保留中文主域名规则与查询参数，并将 `www` 和 `en` 子域名后续产生的 301 规则分开维护。
-
本文继续记录 WordPress + Polylang 英文站从 /en/ 迁移到 en.shuijingwanwq.com 之后的 CDN 与缓存配置过程。前一篇文章已经解决了源站侧的 Polylang 多域名配置、W3 Total Cache Page Cache 兼容、Redis Object Cache 旧配置缓存等问题。本文重点处理 en.shuijingwanwq.com 接入 Cloudflare、启用 HTML 页面缓存、验证首页与文章页 MISS 到 HIT、确认登录用户 Cookie、REST API、登录页和后台入口不会被缓存，并最终通过 Nginx 将非 www 域名下的后台入口统一 301 到 www.shuijingwanwq.com。
-
本文记录一次将 WordPress + Polylang 英文站从路径模式 /en/ 迁移到独立子域名 en.shuijingwanwq.com 的完整排查过程。迁移过程中并不是简单修改 Polylang URL 设置就结束了，而是连续遇到了 Polylang 保存失败、扩展插件 Fatal Error、W3 Total Cache 将英文子域名误判为 foreign domain 并 301 回主域名、Redis Object Cache 缓存旧语言配置等问题。最终通过修复 Polylang 扩展插件、添加 W3TC 兼容 mu-plugin、清理 Redis 对象缓存，并验证 html lang、canonical、hreflang 和 W3TC 页面缓存文件，完成了英文子域名的源站侧迁移。
-
本文记录了一次在 OneinStack 已有 Nginx 虚拟主机中追加 en.shuijingwanwq.com 子域名，并重新签发包含多个域名的 SSL 证书的实操过程。由于主站已经有稳定访问量，且 Nginx 配置中包含多项自定义规则，作者没有采用“删除虚拟主机后重新添加”的方式，而是选择在现有 vhost 中追加 server_name、调整跳转规则、检查 Nginx 配置、添加 DNS 解析，并通过 acme.sh 重新签发和安装证书。文章也说明了这一步是后续将 WordPress 英文站从 /en/ 迁移到 en.shuijingwanwq.com 的服务器与证书准备工作。
-
这篇博客记录了一次 WordPress 核心升级失败的完整排查过程：在从 WordPress 7.0 升级到 7.0.1 时，后台反复出现 524 超时和“另一更新正在进行”的提示。通过检查 `core_updater.lock`、WordPress 当前版本、升级临时目录、文件权限以及 EdgeOne 转发状态，最终确认 WordPress 核心文件并未半升级，问题主要集中在经过 CDN 代理后的后台长请求超时。文章进一步总结出：前台页面适合继续走 EdgeOne 缓存，而 WordPress 后台更新、插件安装等维护操作，后续应考虑通过独立后台域名或源站直连方式处理，以避免 CDN 对后台长请求造成干扰。
-
本文记录了在 OneinStack 环境下排查 WordPress 与 W3 Total Cache 缓存未生效问题的全过程。针对响应头显示动态生成而插件显示已启用的矛盾，文章验证了 Redis 状态与 Nginx 配置，分析了 Disk: Enhanced 模式的依赖性及 Response Headers 的误读。作者最终修正了初始结论，确认在此环境下 W3 Total Cache Page Cache 默认生效，无需额外 Nginx 重写或配置，并通过关闭 Page Cache 保留 Redis Object Cache 优化了架构。
-
本文介绍了如何解决 WordPress English 语言下残留的中文标签问题。通过分析别名冲突的根源，采用修改中文标签名称以匹配 Slug 的方案，结合 Go 脚本重新生成映射并执行标签合并。最终实现了自动化的标签清理、生成 Nginx 301 跳转规则及传递权重，彻底解决了 404 错误问题。
-
WordPress 站点配置 Nginx 全局限流后，后台编辑文章时出现标签保存失败及 429 错误。经排查发现，Gutenberg 编辑器处理标签时会频繁调用 REST API，导致触发了每秒 6 次的严格限流阈值。最终通过将 Nginx 限流速率调升至 30 次/秒并增加突发缓冲，消除了 429 拦截，恢复了标签功能的正常保存，同时保留了基本的安全防护能力。