1Panel 里已经装着 PostgreSQL 和 Redis，DBX 也显示“运行中”，可新建连接时一直超时。很多时候不是密码错了，而是把三个不同的位置当成了同一个 localhost：自己的电脑、VPS 宿主机、Docker 容器。
本文围绕这个常见场景展开：在一台使用 1Panel 的 VPS 上部署 DBX，接入现有数据库，并把浏览器访问和数据库访问分开安排。重点不在多装一个应用，而在装完之后能解释清楚每个地址、端口和账号的用途。
安装前，先记下现有数据库在哪里
不需要把数据库密码贴到笔记里，只记录几项非敏感信息：数据库类型、所在容器、所属 Docker 网络、容器内端口，以及数据库名称。通过服务器终端查看：
sudo docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}'
sudo docker network ls
容器名可以识别实例，镜像可以识别类型，Ports 列则能帮助分辨宿主机映射与容器端口。比如某个 PostgreSQL 显示 127.0.0.1:15432->5432/tcp，含义是宿主机15432转到容器5432。DBX 若与它处在同一个用户自定义网络，通常应访问容器名的5432，而不是拿15432去访问那个容器名。
查看某个容器的网络，不必打印它的全部环境变量：
sudo docker inspect --format '{{json .NetworkSettings.Networks}}' YOUR_DATABASE_CONTAINER
命令中的名字替换成实际容器名。1Panel 不同安装环境的容器名和网络名未必一致，教程里的 postgres、database-net 都只能当示例，不能凭名字猜你的机器。
从应用商店安装，先保存入口密码
官方文档已经给出 1Panel 安装路径：进入应用商店，搜索 DBX，选择版本，核对端口和访问密码后安装。若应用列表找不到，先检查商店同步情况；没有必要随便下载来路不明的第三方安装包。DBX 的 1Panel 部署文档
这里的“访问密码”用于打开 DBX Web，不是 PostgreSQL 密码，也不是 1Panel 管理员密码。分别保存在密码管理器里，用实例名称区分。几个月以后排查时，名字清楚比记忆力可靠。
应用商店的页面和默认值可能随版本变化，安装后要检查最终端口绑定。若管理入口只供自己使用，优先限制在受控网络，或者配置回环监听后使用 SSH 转发。不要因为安装页面给出了 http://IP:4224，就把长期运维方式也停留在公网明文 HTTP。
需要一台独立练习机时，可以看看雨云云服务器。已有 1Panel 环境则通常可以复用，关键是可用内存、磁盘余量和到数据库的网络。选择预装面板只省去面板安装，不会替你配置数据库权限、连接网络和恢复方案。
希望自己管理 Compose，可以这样部署
应用商店和自建 Compose 二选一即可，不要同时在同一个4224端口启动两份 DBX。下面使用 Docker Hub 的 0.6.29，把网页监听限制在回环地址。
mkdir -p ~/services/dbx-panel
cd ~/services/dbx-panel
umask 077
printf 'DBX_PASSWORD=%s\n' "$(openssl rand -hex 24)" > .env
chmod 600 .env
创建 compose.yaml，把外部网络名替换成前面查到的名称。运行前确认该网络确实存在，且包含你准备连接的数据库。
name: dbx-panel
services:
dbx:
image: t8y2/dbx:0.6.29
restart: unless-stopped
ports:
- "127.0.0.1:4224:4224"
environment:
DBX_PASSWORD: ${DBX_PASSWORD:?请先设置入口密码}
volumes:
- dbx-data:/app/data
networks:
- database-net
stop_grace_period: 90s
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
volumes:
dbx-data:
networks:
database-net:
external: true
name: your-existing-database-network
然后执行：
docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps
external: true 表示复用已经存在的网络，不会创建另一个同名替代品。网络不存在时启动报错，应先核对名字，不要把报错当成数据库故障。临时用 docker network connect 接进去可以用于诊断，但长期配置还是写回 Compose，否则下次重建容易丢失。
在本机运行 ssh -N -L 14224:127.0.0.1:4224 your-user@your-vps，再打开 http://127.0.0.1:14224。首次登录使用 .env 里的入口密码。不要把 .env 发到公开求助帖。
连接 PostgreSQL：先验证身份，再看表
在 DBX 新建 PostgreSQL 连接，填写数据库容器在共享网络中的名称、5432、库名和独立数据库账号。测试成功后保存，打开查询窗口执行：
SELECT current_database() AS database_name,
current_user AS login_role,
current_schema() AS schema_name;
如果库名不对，先修正连接，不要靠在错误连接里不断切换找表。生产、测试和演示连接使用明显不同的名字，例如 prod-blog-readonly、test-blog、demo-db。能用颜色区分时也可以加上颜色，但名称本身就应该足够清楚。
截图为隔离环境，示例数据与实际站点无关。
只需要查询时，由数据库管理员创建专门角色。下面假定数据库为 appdb，Schema 为 public，表由 app_owner 创建；应按实际环境替换。密码通过 psql 的交互命令设置，避免把它写在共享 SQL 文件里。
CREATE ROLE dbx_reader LOGIN;
GRANT CONNECT ON DATABASE appdb TO dbx_reader;
GRANT USAGE ON SCHEMA public TO dbx_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO dbx_reader;
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA public
GRANT SELECT ON TABLES TO dbx_reader;
在 psql 中执行 \password dbx_reader 设置密码。默认权限语句只影响指定创建者以后创建的对象；若应用用多个角色建表，需要逐一考虑。已有表权限和未来表权限不是一回事。PostgreSQL GRANT、默认权限
在专用演示库里验证读取和拒绝写入，然后才把同样思路用于正式环境。不要为了测试只读账号，拿一条真实业务记录执行无条件更新。
Redis 的地址相似，使用方式不同
Redis 同样可以用共享网络里的容器名和6379连接，但它不是另一张 SQL 表。确认所用数据库编号、认证方式，以及 Redis ACL 是否要求用户名。只填密码适用于某些配置，不适用于所有实例。
查询缓存时先限定键前缀，例如 demo:* 或某个应用的命名空间。大量键值、超大集合和完整扫描仍会消耗数据库资源，换成图形界面并不会让这些操作免费。DBX 提供 Redis 专用工作台，具体可用操作取决于连接和版本。Redis 工作台文档
生产缓存账号也要按需要授权。只读工作台不该持有日常用不到的管理命令权限，尤其是清空数据库、改配置和任意写入。数据库侧权限、DBX 连接只读和网络限制，各自解决不同问题，不能只留其中一层。
反向代理在哪里，上游就从哪里计算
如果使用宿主机 Caddy，代理到回环端口即可：
db.example.com {
reverse_proxy 127.0.0.1:4224
}
如果使用 1Panel 管理的容器化代理，则先确认代理容器能否访问上游。容器里的回环地址不是宿主机的回环地址。比较清楚的做法是让代理与 DBX 共享专用网络，通过 DBX 网络别名和4224访问；数据库本身不需要跟着发布公网端口。
不管选哪一种，都先保留已有站点配置，再新增管理器域名。验证配置、重载代理、检查 HTTPS、登录和查询，按顺序进行。这里是管理入口，不需要做搜索引擎收录，也没有必要给它挂在主站目录下制造额外路径问题。
按错误现象排查，比反复重装快
connection refused 常见于地址或端口有误、服务没监听；超时更像网络路径或来源限制；认证失败说明至少已经走到了认证阶段。能登录但看不到表，则要检查库、Schema 和元数据权限。这些是排查方向，具体结论仍以服务日志为准。
网页502时也别先改数据库密码。先在代理所在位置测试 DBX 的 Web 上游；网页正常、只有某条连接失败时，再看数据库链路。重装会擦掉很多线索，还可能生成一份新的空数据目录，让问题看起来更多。
安装后保留一张自己的地址表：浏览器入口域名、代理上游、DBX数据卷、数据库网络别名、数据库账号用途。不要记录明文密码。下次更新后只要这几项没发生意外变化，排查范围就很小。
**本文验证范围：**2026 年 9 月 30 日，在本地隔离 Docker 环境运行 DBX 0.6.29（ARM64）与 PostgreSQL 18.6，完成网页密码登录、保存连接、三行样例查询，以及数据库只读角色拒绝 UPDATE 的检查；停止 DBX 后备份完整卷，恢复到独立卷与端口，再次登录并使用保存的连接查询成功。本文没有在生产 VPS 安装 DBX；1Panel 点击安装、公网证书签发、MongoDB、文件数据库、批量导入导出和跨版本升级未作实测，相关步骤依据官方资料与部署原理说明。
DBX 在这套环境里的价值，是把日常查表和看缓存集中到一个浏览器入口。让它稳定工作的基础，仍是那几件朴素的事：地址填对、权限给够但不多给、数据目录保住、更新前能恢复。