Nginx 无法连接到 Octane 监听的端口

Nginx 访问日志，问题已经很清晰了：Octane 服务在 09:10 左右崩溃了，之后所有请求都变成了 502（Bad Gateway），而在此之前的部分请求已经出现了 500 错误。

📊 日志关键时间线

🔍 核心问题分析

1. 502 说明 Octane 进程已死
09:10 之后所有请求都是 502，这意味着 Nginx 无法连接到 Octane 监听的端口（通常是 127.0.0.1:8000）。你的 Octane Worker 进程在 09:10 左右崩溃了，与你之前看到的 swoole-server:122 错误完全吻合。

2. 500 错误响应体异常巨大
09:31 之后，/post/GbTm36Mf 和 /post/Rru2fBBb 返回 500，但响应体大小达到 375KB 甚至 1MB。正常 Laravel 错误页面不可能这么大。这说明：

• 要么是 Octane 在崩溃前输出了大量调试信息

• 要么是某个缓存/日志机制在反复写入错误内容

• 很可能是 Worker 进程异常时，错误被反复堆叠输出

3. 09:38 之后的 403
403 通常是 Nginx 层面的拦截（比如 WAF、防火墙、或 deny 规则），可能是你或服务商在发现异常后启用了防护。

🛠️ 立即排查步骤

第一步：确认 Octane 进程状态

# 查看 Octane 进程是否还在
ps aux | grep octane
# 查看端口监听
ss -tlnp | grep 8000

如果进程已死，日志中应该有更详细的崩溃信息。查看 Octane 自己的日志：

tail -n 200 /www/wwwroot/www.madama.cn/storage/logs/swoole_http.log
tail -n 200 /www/wwwroot/www.madama.cn/storage/logs/laravel.log

第二步：查看系统级 OOM 记录
swoole-server:122 的 handle() on null 错误，常见诱因是 Worker 进程被系统 OOM Killer 杀掉，导致对象引用失效。检查：

dmesg | grep -i "killed process"
grep -i "out of memory" /var/log/syslog

第三步：临时切换到 PHP-FPM 验证
为了先恢复网站访问，可以临时把 Nginx 切回 PHP-FPM 模式（fastcgi_pass），确认应用本身没有代码问题。如果 FPM 下一切正常，那问题就锁定在 Octane 的稳定性上。

💡 针对 Octane 崩溃的常见修复

1. 降低 Worker 内存压力
在 config/octane.php 中调整：

'workers' => 2,  // 减少 worker 数量
'max_requests' => 500,  // 每个 worker 处理 500 请求后重启，避免内存泄漏

2. 禁用 Swoole 短名称（避免函数冲突）
在 php.ini 中设置：

swoole.use_shortname = off

然后重启 Octane。

3. 检查是否有阻塞操作
Octane 是常驻内存的，任何阻塞操作（如同步 HTTP 请求、sleep()、大文件同步读写）都会拖垮整个 Worker。检查你的 Fresns 插件或主题中是否有这类代码。

4. 升级 Laravel Octane
你当前使用的版本可能存在已知的 Swoole 兼容性 bug。可以尝试：

composer update laravel/octane

📌 建议的恢复顺序

1. 先切回 PHP-FPM，恢复网站可用性

2. 查看 laravel.log 和 swoole_http.log，定位 09:10 崩溃的具体异常

3. 检查系统 OOM 记录，确认是否是内存不足

4. 根据日志修复后，再重新启用 Octane，并设置 max_requests 定期重启 Worker

如果你能把 storage/logs/laravel.log 中 09:10 前后的错误内容贴出来，我可以帮你进一步定位具体的崩溃原因。