📍 WDQWDWQD987AAAAA:216.73.217.18
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7cddaae02234.html
📄

WordPress更换服务器 - 日志中应该核对哪些字段

WordPress更换服务器后，日志里最该核对的字段是：请求时间、客户端IP、请求方法、请求URL、HTTP状态码、响应大小、响应耗时、User-Agent、Referer，以及PHP错误日志中的时间戳、错误级别、文件路径、行号、函数调用栈和MySQL错误码。判断迁移是否成功，不能只看首页能否打开，而要看这些字段是否与旧服务器基线一致，异常是否集中在特定URL、特定IP或特定时间段。

先确定日志来源，再决定核对哪些字段

WordPress更换服务器后，常见日志分四类，字段含义不同：

• Web服务器访问日志：Nginx或Apache记录每个请求。重点看时间、IP、方法、URL、状态码、字节数、耗时、User-Agent、Referer。
• PHP错误日志：记录时间戳、错误级别、错误信息、文件路径、行号。迁移后路径变化、扩展缺失、权限错误常在这里暴露。
• MySQL慢查询与错误日志：看时间、查询耗时、锁等待时间、错误码、SQL语句摘要。数据库连接信息变更后，这里可能出现连接拒绝或超时。
• WordPress调试日志：在wp-config.php中开启WP_DEBUG_LOG后生成，记录PHP notice、warning、fatal error及插件抛出的异常。

先确认日志文件的实际路径和轮转方式，再逐项比对。不同主机面板的日志位置不同，应以服务器配置文件中的access_log、error_log指令为准。

访问日志中必须逐项核对的字段

以下字段建议在迁移前后各取一段相同长度的日志做对比：

1. 时间戳：确认时区是否一致。旧服务器用UTC、新服务器用本地时间，会导致日志时间整体偏移，影响故障定位。
2. 客户端IP：如果新服务器前面加了CDN或反向代理，日志里可能全是代理IP。此时要检查X-Forwarded-For或X-Real-IP是否被正确记录，否则无法判断真实来源。
3. 请求方法与URL：核对是否存在大量404或301。迁移后固定链接、上传目录、插件接口路径可能变化，日志中的URL能直接指出哪些资源失效。
4. HTTP状态码：重点看5xx和404的比例。少量404可能是旧链接，持续5xx通常指向PHP进程、数据库连接或文件权限问题。
5. 响应大小与耗时：同一URL在迁移后响应体明显变小，可能是被截断或返回了错误页；耗时突然升高，可能与新服务器磁盘、数据库或网络有关。
6. User-Agent与Referer：用于区分真实用户、搜索引擎爬虫和监控请求。如果某个爬虫的请求全部返回5xx，说明它对某些路径的访问触发了服务端问题。

判断结果时，不要只看单条日志。把状态码按URL聚合，把耗时按小时聚合，才能看出是全局问题还是局部问题。

PHP与数据库日志中的关键字段

访问日志只能说明“请求失败了”，PHP和数据库日志才能说明“为什么失败”。核对时重点看：

• 时间戳：与访问日志对齐，确认错误发生在哪个请求之后。
• 错误级别：Fatal error、Warning、Notice的处理优先级不同。迁移后大量Warning可能只是提示，但Fatal error会直接导致白屏。
• 文件路径与行号：迁移后绝对路径变化，旧路径残留会出现在错误信息里。核对路径是否指向新服务器的实际目录。
• 函数调用栈：定位是主题、插件还是核心文件触发。调用栈能区分“可能原因”和“已经定位的原因”。
• MySQL错误码：如连接拒绝、超时、表不存在。错误码比错误描述更稳定，便于检索和比对。

如果日志中出现Access denied，先核对数据库用户名、密码、主机授权，而不是直接改权限。如果出现No such file or directory，先核对wp-config.php中的路径和上传目录权限。

用一份可执行的核对清单验收迁移结果

假设旧服务器日均访问日志为1万条，迁移后取新服务器同一时段的1万条日志，按以下步骤核对：

1. 导出两段日志，按小时统计状态码分布，对比5xx和404的占比变化。
2. 筛选耗时超过3秒的请求，按URL聚合，确认是否集中在数据库查询或外部接口调用。
3. 搜索PHP错误日志中的Fatal error，逐条记录文件路径和行号，确认是否已修复。
4. 检查MySQL慢查询日志，确认迁移后是否出现新的慢查询模式。
5. 用curl -I或浏览器开发者工具抽查关键URL，确认状态码与日志记录一致。

适用条件是：新服务器已能正常响应请求，且日志采集已开启。如果日志本身没有写入，先解决日志配置问题，再谈字段核对。判断结果是：状态码分布与旧服务器接近、无持续Fatal error、慢查询没有明显增加，才算迁移基本稳定。

下一步：建立迁移后的日志基线

完成上述核对后，把新服务器正常状态下的日志字段分布保存为基线，包括各状态码比例、平均响应耗时、常见User-Agent列表。后续出现异常时，直接与这份基线对比，比凭感觉判断更快。同时确认日志轮转和保留周期，避免磁盘被写满后丢失关键记录。