Coolify项目中Supabase与PostgreSQL公共端口配置问题解析

在Coolify v4.0.0-beta.395版本中，用户在使用Supabase资源时遇到一个典型的容器网络配置问题。当尝试为PostgreSQL数据库设置公共端口5432并启用公开访问时，系统自动创建的Nginx代理容器会不断重启，导致数据库连接失败。

问题现象

用户部署Supabase资源后，在PostgreSQL容器设置中启用公共端口5432。系统随后创建了一个基于nginx:stable-alpine镜像的代理容器。然而观察发现，该Nginx容器每隔约10秒就会重启一次，日志中显示关键错误信息："host not found in upstream"。

技术原理分析

这个问题源于Coolify在生成Nginx配置时对容器名称解析的错误处理。正常情况下，Coolify应该识别Supabase独立部署模式下的PostgreSQL容器命名规则（supabase-db-xxxx），但当前版本中却错误地使用了简化的"postgres"作为上游主机名。

根本原因

问题的核心在于服务数据库模型中的容器名称解析逻辑。在早期版本中，代码能够正确返回"standalone-supabase/postgres"格式，从而生成正确的容器名称。但在当前版本中，该逻辑被简化为仅返回"postgres"，导致Nginx配置中使用了错误的上游主机名。

临时解决方案

对于急需解决问题的用户，可以采取以下临时方案：

1. 手动编辑Supabase的docker-compose配置
2. 在supabase-db服务部分直接添加端口映射：

ports:
  - 5432:5432

安全建议

值得注意的是，将数据库直接暴露在公共网络中会带来严重的安全风险。系统会不断受到端口探测和未授权访问尝试。建议用户考虑以下替代方案：

1. 使用SSH隧道建立安全连接
2. 配置IP白名单限制访问来源
3. 使用专用网络接入私有环境

版本更新展望

Coolify开发团队已经确认此问题，并计划在后续版本中修复。新版本将恢复正确的容器名称解析逻辑，确保Nginx代理能够正确连接到PostgreSQL服务。

对于技术用户而言，理解这类容器网络问题有助于更好地排查和解决云原生环境中的连接性问题。这类问题通常涉及DNS解析、容器命名和网络配置等多个层面的交互，需要系统性地分析和处理。