ToolJet Docker 部署：Invalid URL

看到 TypeError [ERR_INVALID_URL]: Invalid URL 时，先检查 .env 中的 TOOLJET_HOST 是否缺失、格式错误，或与当前镜像版本不匹配，再查看容器日志。依照与该镜像对应的 ToolJet 官方 Docker 文档修正配置并重建容器，再检查 PostgreSQL、端口和发布地址；这种启动错误通常与浏览器无关。

容器启动后立即退出时，不要急着重装，先取得退出码和首个异常堆栈。ToolJet 运行依赖的平台数据库，与编辑器里添加的业务数据源是两套独立连接。远程访问则要依次核对端口发布情况、防火墙或安全组放行情况，以及客户端能够访问的公开地址。

Invalid URL 指向 TOOLJET_HOST

以下堆栈来自一篇 ToolJet Docker 部署记录。异常发生在 setSecurityHeaders，末行还出现了 input: 'undefined'，说明 URL 构造器实际收到的是未定义值。应先检查传给应用的地址变量。

TypeError [ERR_INVALID_URL]: Invalid URL
    at new NodeError (node:internal/errors:405:5)
    at new URL (node:internal/url:637:13)
    at setSecurityHeaders (/app/server/dist/src/main.js:43:18)
    at bootstrap (/app/server/dist/src/main.js:148:5)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
{ input: 'undefined', code: 'ERR_INVALID_URL' }

该社区记录指出，TOOLJET_HOST 可以设为服务器地址或自定义域名；在那个版本中，没有把它写进 .env 也会触发错误。变量名、地址格式和端口要求仍应以实际镜像标签所对应的官方文档为准。

# 仅用于本机验证；端口按当前 Compose 的宿主机映射调整
TOOLJET_HOST=http://localhost:8080

# 对外发布时改用客户端能够访问的域名
# TOOLJET_HOST=https://tooljet.example.com

修改后重新应用配置，并立即查看日志：

docker compose config --services
docker compose up -d
docker compose logs --tail=200 tooljet

如果 docker compose config --services 返回的服务名不是 tooljet，日志命令中的名称也要相应替换。排查期间可以确认 Compose 实际加载了哪个镜像标签，但不要把包含密码的完整配置直接贴到公开场合。

容器秒退先看退出原因

先把现象分成三类：服务未创建、创建后立即退出，或不断重启并退出。社区排障记录也建议先区分失败表现，再处理环境变量、依赖服务和端口，而不是直接清理环境。

docker compose ps -a
docker compose config --services
docker compose logs --tail=200 tooljet
docker inspect tooljet --format '{{.State.Status}} {{.State.ExitCode}} {{.State.Error}}'

docker inspect 中的 tooljet 同样要替换成真实容器名。按固定顺序检查必填环境变量是否传入、Compose 使用的 PostgreSQL、Redis 等依赖是否就绪，以及宿主机端口是否已被占用。不要在尚未备份时使用会删除数据卷的清理命令。

平台库和业务库要分开

ToolJet 运行依赖的平台数据库，与在编辑器中配置的 PostgreSQL、MongoDB、Elasticsearch、REST API 等业务数据源是两套独立连接。 平台数据库缺失会导致平台启动或初始化失败；业务数据源连接失败通常只影响对应应用或查询。

以下变量关系来自一篇较早的社区记录，只能用于理解配置结构，不能直接作为新版默认值。

PG_DB=<应用数据库名>
TOOLJET_DB=<另一数据库名>
PGRST_DB_URI=postgres://<user>:<password>@<db-host>:5432/<应用数据库名>

具体建库、初始化和迁移步骤应以 ToolJet 官方 Docker 文档 为准。 数据库连接失败时，从日志中优先查找 connection refused、authentication failed 和数据库不存在等错误：

docker compose logs --tail=200 tooljet

如果 PostgreSQL 运行在宿主机上，容器里的 localhost 指向容器自身，不能用它代替宿主机地址；同一 Compose 网络中的数据库则应使用容器服务名，并确认端口、账号和目标数据库与配置一致。

远程访问先核对端口

远程访问失败要逐层检查。docker compose ps 应能看到发布到宿主机的端口，ss 则用于确认进程确实在监听；之后再检查主机防火墙和云服务器安全组是否放行。

docker compose ps
sudo ss -lntp

局域网访问使用 http://<服务器IP>:<映射端口>。社区记录中出现过 8087 的示例，但实际端口必须以自己的 Compose 配置为准。 同时要把 TOOLJET_HOST 改成客户端能够访问的地址，否则，即使本机能打开，也不能说明重定向和公开地址配置正确。

公网环境更适合使用实际域名并通过 HTTPS 反向代理发布。没有公网 IP 时，可以把内网穿透作为备选。旧社区实践使用 tooljet/try 镜像、宿主机 80 端口和 cpolar，这些只能作为历史线索，执行前应核对当前镜像与官方安装说明。

# 社区旧实践中的安装方式；执行前应核对当前官方安装文档
sudo curl https://get.cpolar.sh | sh
sudo systemctl status cpolar

旧实践通过 http://localhost:9200 进入 cpolar 管理界面。正式使用时应确认管理端口没有暴露到公网，并从当前控制台读取实际隧道地址。

下一步收集最小诊断信息

如果仍然无法启动，先收集下面这些信息，不必先重装整套环境：

docker compose version
docker version
docker compose images
docker compose ps -a
docker compose logs --tail=200 tooljet

继续定位时，贴出 ToolJet 镜像标签、Compose 服务名、首个异常堆栈及报错前后约 100～200 行日志，再附上脱敏后的 TOOLJET_HOST、数据库主机、端口和库名。密码、令牌以及完整数据库连接串必须先删除。