修复Docker下的http协议导致Typecho小程序的网络连接错误

第一步:执行诊断命令
在你的服务器上运行以下命令,-vk 参数会显示详细的SSL握手和请求过程,--http1.1 用于避免HTTP/2干扰:

bash
curl -vk --http1.1 https://www.域名.cn/api/noticeList

请提供完整的输出,特别是:

  • Connected to www.域名.cn (IP) port 443 之后的信息。

是否有 * SSL certificate verify ok. 或类似的证书验证信息。

错误发生在哪个阶段(正在发送请求时,还是接收响应时)。

第二步:进行关键的外部直连测试
这一步至关重要! 请在你的个人电脑上,使用家庭或手机网络,执行:

bash
curl -v http://回源.域名.cn:端口/api/noticeList

务必确认第三步(服务器内部测试 127.0.0.1:8080)已能返回正确JSON,这是所有对外服务的基础。如果它仍有500错误,那么所有外部请求最终都会失败,我们必须优先彻底解决它。

测试方式 关键现象与错误信息 原因分析
外部直连
(http://回源...:端口) HTTP 500 错误,页面显示:Call to undefined method Typecho\Response::throwJson() 核心问题:你正在使用的某个Typecho插件或小程序适配代码调用了已不存在的方法。在Typecho 1.2版本中,官方移除了Response类中的throwJson和throwXml方法。
通过CDN访问
(https://www...) SSL握手成功,但在发送请求后连接被对端重置 (Connection reset by peer) 衍生现象:因为CDN将请求转发到了你的源站(Typecho应用),而源站因上述致命错误无法生成有效的HTTP响应,导致CDN或Apache异常关闭了连接。
解决方案:修复Typecho应用错误
这是解决问题的唯一正确路径,所有网络层面的调试都必须在此之后进行。

第一步:修复缺失的 throwJson 方法
你需要手动将这个方法添加回Typecho的核心文件中。具体操作步骤如下:

进入Docker容器:

bash
docker exec -it 容器id /bin/bash

编辑核心文件:编辑文件 /var/www/html/var/Typecho/Response.php

bash
vi /var/www/html/var/Typecho/Response.php

添加方法代码:在Response类中找到合适的位置(例如其他方法附近),添加以下代码:


/**
 * 抛出json回执信息
 *
 * @access public
 * @param mixed $message 消息体
 * @return void
 */
public function throwJson($message)
{
    /** 设置http头信息 */
    $this->setContentType('application/json');
    echo json_encode($message);
    /** 终止后续输出 */
    exit;
}

保存并退出,然后重启Apache服务或重启Docker容器使改动生效。

第二步:验证修复
在宿主机上执行内部测试,确认应用错误已解决:

bash
curl -s http://127.0.0.1:8080/api/noticeList | head -c 200

期望结果:看到以 {"code":... 开头的JSON数据,而不是HTML错误页面。

第三步:检查并更新插件/适配代码(治本)
上述修改只是临时兼容。从长远看,你应该:

检查是哪个插件或小程序适配代码调用了旧的throwJson方法。

寻找该插件针对Typecho 1.2的更新版本,或将其代码中调用throwJson的地方,修改为直接使用$response->setContentType('application/json')和echo json_encode(...)的方式。

应用修复后的后续检查
当你的Typecho应用能正常返回JSON后,之前“连接被重置”的问题大概率会随之消失。如果问题依旧,你只需检查并确保:

CDN回源配置正确指向了可用的 http://回源.域名.cn:端口。

小程序后台的request合法域名已正确设置为 https://www.域名.cn

总结
现在问题的核心非常明确:必须先修复Typecho应用内部的500错误(throwJson方法缺失),所有网络连通性问题都是这个原因导致的表象。

请先专注于在Docker容器内完成第一步修复,这是让一切恢复正常的基础

Last modification:December 19, 2025
If you think my article is useful to you, please feel free to appreciate