WordPress主机迁移：错误只在特定时段出现时怎样捕捉短暂证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /afe14fa97c7a.html
📄
WordPress主机迁移：错误只在特定时段出现时怎样捕捉短暂证据
结论先给：如果错误只在特定时段出现，迁移后不要先改配置，而要把“时段”本身当成证据来采集。只有当你能把错误时段与迁移后的某个可观测差异对上，才值得动配置；对不上时，改配置只会把问题从可复现变成不可复现。
先分清两类时段性错误
迁移后只在特定时段报错，通常落在两种机制里。第一种是资源竞争：备份、日志切割、定时任务、缓存重建、爬虫集中抓取，都可能在固定窗口挤占 CPU、内存、数据库连接或磁盘 IO。第二种是环境差异：新主机与原主机在 PHP 版本、扩展、时区、DNS 解析、反向代理、对象存储或 CDN 回源上的差异，只在某些请求路径或某些时段被触发。
区分方法不是看错误文案，而是看错误是否随“时段”移动。把迁移后新增的定时任务临时停掉一个周期，如果错误窗口随之消失，资源竞争的可能性上升；如果窗口不变，环境差异或外部流量节律更值得怀疑。
用时间戳把短暂错误固定下来
短暂错误最难的地方是它消失得快，事后只剩一句“刚才打不开”。可行的做法是让证据在错误发生时自动落盘，而不是靠人回忆。至少记录四类带时间戳的信息：
- 服务器端错误日志中的时间、请求路径、PHP 错误级别与堆栈首行；
- Web 服务器访问日志中同一秒的状态码分布，尤其是 5xx 与 499、502、504 的比例；
- 主机层面的资源采样，间隔压到一分钟以内，覆盖 CPU、内存、数据库连接数与磁盘等待；
- 外部可用性探测的结果，从至少两个不同网络位置发起，避免单点网络抖动被误判为站点故障。
这些记录要统一时区。迁移前后主机时区不一致时，日志时间会整体偏移，两个时段看起来错开，实际是同一事件。先把时区对齐再比对，否则后面的推断全部作废。
一个假设例子：错误窗口与备份窗口重合
假设迁移后每天凌晨 2:10 到 2:25 出现 504，其余时段正常。原主机备份在凌晨 4 点，新主机面板默认备份时间改成了凌晨 2 点，同时数据库连接数上限比原主机低。这个组合下，备份期间的 IO 与连接占用可能把响应时间推过网关超时阈值。
验证动作：把备份时间临时挪到业务低谷之外的另一个窗口，观察 504 是否跟着移动。如果错误窗口跟着备份移动，资源竞争基本成立，下一步应调整备份方式、连接数上限或超时阈值，而不是去改主题代码。如果错误窗口不动，说明备份不是主因，应转向 DNS、CDN 回源或上游网络在该时段的节律。
这个例子的数字只是说明比较方法，不代表任何真实主机的默认配置。关键是让“改动”和“窗口移动”之间形成可观察的对应关系。
哪些情况会让上面的结论失效
反例是：错误窗口与任何迁移后新增任务都不重合，却与外部流量高峰重合。这时资源竞争的判断会让位于流量节律或缓存策略。另一种失效情形是错误由第三方服务在该时段的限流或维护引起，本地日志只能看到超时，看不到对方侧的原因。此时继续在主机内部找原因会浪费时间，应先用外部探测和响应头确认请求是否已经离开本站。
还有一种容易被忽略的情况：错误只在特定时段出现，是因为该时段才有特定类型的请求，例如定时同步、批量导入或后台任务。错误不是时段造成的，而是请求类型造成的，时段只是它的外壳。
下一步动作与结果如何影响决策
先做一次不改动生产环境的证据采集，持续覆盖至少三个完整错误周期。如果三个周期里错误窗口稳定且与某个迁移后差异对应，就针对该差异做单变量调整，并保留调整前后的时间戳对照。如果窗口不稳定或对不上任何差异，下一步不是继续猜，而是把采集范围扩大到 DNS 解析结果、CDN 回源日志和上游网络路径，确认请求在离开本站之后发生了什么。
只有证据能把错误时段与某个具体差异绑定，配置调整才是可复查的；绑定不了时，任何改动都只是把短暂错误换成了另一种短暂错误。
