S3 ObjectStoreService hangs indefinitely when HTTPS is attempted against a non-TLS endpoint

快速结论：该问题通常出现在 n8n 启用 S3 二进制存储、但 N8N_EXTERNAL_STORAGE_S3_HOST 指向仅支持明文 HTTP 的 S3 兼容服务（如 SeaweedFS）且未显式设置 N8N_EXTERNAL_STORAGE_S3_PROTOCOL 时：默认 https 触发 AWS SDK 的 TLS 握手并无限挂起，阻塞启动流程。优先排查协议配置与主机端口是否匹配。

适用环境：n8n 2.17.0（2.16.0 亦可复现）；Node.js 22.22.0；自托管 Kubernetes 部署（queue 模式）；数据库 PostgreSQL；二进制数据存储为 S3。本地复现环境为 macOS 15.4。

最快修复方案：将 N8N_EXTERNAL_STORAGE_S3_PROTOCOL 显式设为 http，并在 N8N_EXTERNAL_STORAGE_S3_HOST 中包含端口（例如 seaweedfs:8333）。该处理已由报告者在其生产部署中验证生效。

注意事项：Issue 中未提供代码级修复（checkConnection() 增加超时与日志）的合并状态，相关 PR 为 #29777，需以实际发布版本为准。此外，该 Issue 因长时间无活动被关闭，未经官方确认修复已合入主线。配置错误的典型表现是进程看似存活、/healthz 返回 200，但编辑器与 API 不可达、就绪探针 503，容易被误判为健康。

问题场景

用户以自托管方式部署 n8n（Kubernetes、queue 模式），通过 N8N_DEFAULT_BINARY_DATA_MODE=s3 或设置 N8N_EXTERNAL_STORAGE_S3_BUCKET_NAME 启用 S3 存储。当 N8N_EXTERNAL_STORAGE_S3_HOST 指向仅支持明文 HTTP 的 S3 兼容服务（如 SeaweedFS 的 seaweedfs:8333），且未设置 N8N_EXTERNAL_STORAGE_S3_PROTOCOL 时，n8n 启动会卡在 ObjectStoreService.init()，所有后续路由注册被阻塞。

报错原文

S3 ObjectStoreService hangs indefinitely when HTTPS is attempted against a non-TLS endpoint

原因分析

最可能的原因是协议不匹配：未显式配置时协议默认为 https，而目标服务只提供明文 HTTP。此时 TCP 连接可以建立，但 TLS 握手无法完成（非 TLS 服务不会返回 ServerHello）。

报告者指出 ObjectStoreService.checkConnection() 中发送 HeadBucketCommand 时没有超时设置，因此该调用会无限挂起。由于 objectStoreService.init() 在启动阶段被 await，后续路由注册全部被阻塞。另一个加重排查难度的因素是启动日志中未输出解析后的 endpoint，运维人员难以确认实际使用的协议与地址。

环境排查

确认 n8n 版本（报告环境为 2.17.0，2.16.0 可复现）与 Node.js 版本（22.22.0）。
确认 N8N_DEFAULT_BINARY_DATA_MODE=s3 或已设置 N8N_EXTERNAL_STORAGE_S3_BUCKET_NAME，即 S3 初始化确实被触发。
确认 N8N_EXTERNAL_STORAGE_S3_HOST 中是否包含端口，以及目标服务实际监听的协议（HTTP/HTTPS）。
确认 N8N_EXTERNAL_STORAGE_S3_PROTOCOL 是否已显式设置，避免落入默认 https。
观察启动日志停在 “Initializing n8n process” 之后、未打印 “Version:” 或 “Editor is now accessible”。
查看 Kubernetes Pod 状态：可能显示 Running 1/1，但除 /healthz 外其余路由返回 404，/healthz/readiness 返回 503。

解决步骤

将 N8N_EXTERNAL_STORAGE_S3_PROTOCOL 显式设置为 http，使其与仅支持明文 HTTP 的 S3 兼容服务一致。
确保 N8N_EXTERNAL_STORAGE_S3_HOST 包含正确的端口，例如 seaweedfs:8333。
重启 n8n 进程或 Pod，使新的环境变量生效。
若问题仍存在，可用本地最小复现进一步确认：启动一个只接受连接但从不响应的 TCP 监听器，再以 N8N_EXTERNAL_STORAGE_S3_HOST=127.0.0.1:9999 和 N8N_EXTERNAL_STORAGE_S3_BUCKET_NAME=test 启动 n8n，观察是否在 “Registered runner” 之后卡住。
如需代码层修复（连接检查超时、启动日志输出解析后的 endpoint、超时可配置），可关注 PR #29777 的合入情况；该方案在 Issue 中未标注为已合并，可优先尝试配置层修复。

验证方法

重启后确认启动日志中不再停留在 “Initializing n8n process”，并正常打印 “Version:” 与 “Editor is now accessible”。随后访问编辑器 UI 与 API 端点，确认不再返回 404；检查 /healthz/readiness 是否返回 200 而非 503。报告者确认，设置 N8N_EXTERNAL_STORAGE_S3_PROTOCOL=http 并在 host 中包含端口后，问题即消失。