一、故障概述

在 Typecho 博客系统执行文章保存操作（POST /action/contents-post-edit）时，页面返回 HTTP 504 Gateway Timeout 错误。对存储、资源、数据库及 PHP 环境进行分层排查后，确认底层运行正常，问题定位为反向代理超时配置。

二、排查过程与实证结果

1、存储系统验证

排查命令：在 Pod 内执行

time touch /var/www/html/nfs_test && echo "test">/var/www/html/nfs_test && rm /var/www/html/nfs_test

实测结果：

real    0m0.125s
user    0m0.000s
sys     0m0.001s

结论：NFS 文件读写操作耗时仅 0.125 秒，无 I/O 延迟或挂载异常，可排除存储瓶颈。

2、资源使用率检查

排查命令：kubectl top pod miiv-lnp-557f547c45-d4745

实测结果：

NAME                        CPU(cores)   MEMORY(bytes)
miiv-lnp-557f547c45-d4745   13m          25Mi

结论：Pod CPU 使用率 13m、内存 25Mi，资源配额充足，无资源争抢或耗尽情况。

3、数据库状态分析

排查命令：SHOW FULL PROCESSLIST;

实测结果：

| Id     | User    | Host            | db      | Command | Time | State    | Info                  |
| 404341 | root    | localhost       | NULL    | Query   |    0 | starting | SHOW FULL PROCESSLIST |
| 404377 | typecho | 10.42.2.3:45330 | typecho | Sleep   |   61 |          | NULL                  |
| 404378 | typecho | 10.42.2.3:45340 | typecho | Sleep   |   61 |          | NULL                  |

结论：数据库连接均为 Sleep 状态，无长时间运行查询，无连接阻塞或死锁，负载正常。

4、PHP 执行能力测试

测试脚本：创建 PHP 文件模拟耗时操作，访问

<?php
echo "Start: " . date('Y-m-d H:i:s') . "\n";
sleep(2); // 模拟耗时操作
echo "End: " . date('Y-m-d H:i:s') . "\n";
?>

实测结果：

Start: 2026-05-02 12:56:03
End: 2026-05-02 12:56:05

结论：PHP-FPM 可正常处理 2 秒耗时请求，脚本执行不受限制，应用层基础处理能力无异常。

5、故障日志定位

日志内容：

10.42.1.2 - - [02/May/2026:12:44:32 +0000] "POST /action/contents-post-edit?_=94be44fc416e098a75bd09ba9d85aec0 HTTP/1.1" 504 569

关键信息：文章保存请求触发 504 超时，与 PHP 正常处理能力测试结果不一致。

结论：问题并非应用层逻辑错误，而是网关层超时配置导致。

6、调整反向代理超时配置

修改 Nginx 或 Ingress Controller 配置，增加proxy_read_timeout和proxy_send_timeout值（建议设置为 120 秒以上）

示例配置（Nginx）：

location~\.php$ {
    proxy_read_timeout 120s;
    proxy_send_timeout 120s;
}

重新发布文章发现正常（耗时还是有问题）

三、根因分析

综合实测数据，系统底层环境（存储、资源、数据库、PHP）均无异常。HTTP 504 错误本质为反向代理等待后端响应超过预设超时阈值。PHP 可正常处理 2 秒耗时请求，说明基础执行能力正常；但文章保存操作可能包含额外处理逻辑（如插件触发、缓存更新等），导致总耗时超过网关默认超时时间（通常为 60 秒）。

四、解决方案

关闭Typecho中的AISummary插件正常

ypecho 动态 IP 环境适配与故障排查指南

场景一：解决动态 IP 导致的后台死链问题

Typecho 是一个使用 PHP 编写的博客系统。在部署环境（如容器、动态 IP 服务器）中，如果域名或 IP 地址不固定，系统生成的后台按钮链接往往会指向旧的 IP 地址或错误的端口，导致访问异常。

为了解决这个问题，我们需要开启相对地址模式。虽然开启后永久链接（伪静态）可能无法正常使用，但这能确保后台按钮在 IP 变动时依然可用。

开启相对地址的两种方法

方法一：修改数据库（不推荐）
直接修改数据库 typecho_options 表，将 siteUrl 字段的值改为相对路径（如 /）。

方法二：修改核心代码（推荐）
通过修改核心文件来绕过后台对“绝对 URL”的强制校验。

操作步骤：

1.定位文件：var/Widget/Options/General.php

2.查找代码（约 87 行）：

->addRule('url', _t('请填写一个合法的URL地址'))

3.修改代码：

->addRule('xssCheck', _t('请填写一个合法的URL地址'))

4.保存文件，刷新后台即可生效。

修改效果：Typecho 后台不再强制校验站点地址协议和域名，后台所有链接自动适配当前访问地址，彻底解决动态 IP / 端口导致的死链问题。

场景二：后台 “Server Error” 排查与修复

访问后台模块（如附件管理）出现 Server Error (500) 且无具体报错时，按以下步骤修复。

1. 开启调试模式

编辑网站根目录 config.inc.php，在 <?php 下方直接粘贴：

// ----------调试使用-------
define('__TYPECHO_DEBUG__', true);
error_reporting(E_ALL);
ini_set('display_errors', 'On');
// 强制输出错误到浏览器，防止被 Nginx 拦截
ini_set('html_errors', 'Off');
// -------------------------

2. 分析报错信息

典型错误：
TypeError: Argument 1 passed to Typecho\Common::mimeIconType() must be of the type string, null given

原因：数据库中部分附件 mime 字段为 NULL，但函数强制要求字符串，导致崩溃。

3. 修复方案

编辑文件：admin/manage-medias.php

修改前（报错）：

<?php $mime = \Typecho\Common::mimeIconType($attachments->attachment->mime); ?>

修改后（修复）：

<?php $mime = \Typecho\Common::mimeIconType($attachments->attachment->mime ?? ''); ?>

修复后完整代码段：

<?php while ($attachments->next()): ?>

<?php $mime = \Typecho\Common::mimeIconType($attachments->attachment->mime ?? ''); ?>

4. 结果与注意

保存后刷新后台，Server Error 消失，附件管理正常显示。

️ 注意：调试完成后，务必注释 / 删除 config.inc.php 里的调试代码，避免生产环境泄露敏感信息。