服务器运维 on 友派博客

Docker + Postgres 密码玄学：一次 Nano 自动换行引发的血案与排错实录

Sun, 26 Apr 2026 21:30:00 +0800

作为一个折腾服务器的独立开发者，经常和 Docker 打交道。本以为 docker-compose up -d 部署个 PostgreSQL 是闭着眼睛都能搞定的常规操作，结果最近却结结实实栽进了一个连环坑里。

报错信息大家都很熟悉：

FATAL: password authentication failed for user "app"

但在我反复核对环境变量、网络配置、甚至是容器间的互通性都没问题后，事情开始变得诡异起来。经过两天的抽丝剥茧，我发现这不仅仅是一个简单的密码拼写错误，而是由幽灵配置、挂载盲区和编辑器特性共同组成的三重陷阱。

这篇博客记录了整个排查过程，希望能帮到同样在终端里怀疑人生的你。

第一重陷阱：“负负得正”的幽灵密码

事情的起因是这样的：我发现新建的应用容器死活连不上 Postgres，但我之前部署的另一个 Auth 服务却能正常连接。

我一开始猜测是不是走 Docker 内部网络（比如 Host=pgsql）就能免密？但 Postgres 的 pg_hba.conf 机制决定了 TCP 连接必须走 scram-sha-256 校验，不可能免密。

通过在容器内部直接 echo 环境变量，我揪出了第一个内鬼——未加引号的 .env 注释。

在早期的项目中，我有个.env文件是这样写的：PGSQL_APP_PASSWORD=app@pgsql # 应用通用密码

然后我在docker-compose.yaml中这样写了：

POSTGRES_APP_PASSWORD: ${PGSQL_APP_PASSWORD:-app@pgsql}

因为.env文件没有加双引号，Docker Compose 粗暴地把后面的空格和中文注释一并吃进了环境变量里。

数据库初始化时，把 app@pgsql # 应用通用密码 当成了完整的密码存了进去。
旧的 Auth 容器读取同样的配置，带着这串超长且带中文的密码去请求，两边竟然完美对上号了（负负得正）！
而我在命令行手动敲写干净的 app@pgsql，自然被无情拒绝。

避坑指南： .env 文件或 docker-compose.yml 中的复杂字符串，特别是带有特殊字符的密码，务必养成加双引号的习惯。

第二重陷阱：被忽视的数据卷（Volume）初始化盲区

发现了上面的问题后，我决定修正配置，改用干净的密码 app#pgsql，并重新启动容器。结果——依然报错！

我进入容器内部打印环境变量，确认 $POSTGRES_APP_PASSWORD 已经是正确的 app#pgsql，为什么还是连不上？

这时候，我注意到了 docker-compose.yml 里的这行代码：

volumes:
 - ./data:/var/lib/postgresql/data

这是 Postgres Docker 镜像的一个经典“潜规则”：只要挂载的目标目录（/var/lib/postgresql/data）不为空，容器启动时就会直接跳过整个初始化流程（包括执行 /docker-entrypoint-initdb.d/ 下的脚本）。

因为我之前已经运行过一次，./data 目录下已经有旧数据了。所以即便我改了配置，重启了容器，数据库里的密码依然是上一次初始化时的那个带中文的“幽灵密码”。

避坑指南： 在开发阶段调试初始化脚本时，如果修改了密码或初始数据库结构，必须清空宿主机的 ./data 目录（rm -rf ./data/*），或者进入容器用 ALTER USER 强制修改密码。

最终 Boss：Nano 复制粘贴的“背刺”

好，我删除了旧数据，确信这次一定会重新初始化，docker logs 也清楚地打印出执行了我的自定义脚本 01-init-user-and-permissions.sh，甚至打出了 NOTICE: User created: app。

满心欢喜地去测试连接。 报错：password authentication failed。

那一刻我真的怀疑自己对 Docker 的认知是不是被篡改了。网络没问题、环境变量没问题、数据也清空重来了，究竟是哪里出了鬼？

直到我打开那个 01-init-user-and-permissions.sh 脚本，一行一行地扫，终于发现了这个极其隐蔽的致命伤：

CREATE USER "$POSTGRES_APP_USER" WITH PASSWORD '$POSTGRES_APP_PASSWO
RD');

是的，你没看错。变量名 $POSTGRES_APP_PASSWORD 被从中间腰斩，换行了！

这是怎么发生的？因为我是直接在 SSH 终端里用 nano 编辑器，把另一个服务器的脚本复制粘贴进去的。当你的终端窗口不够宽，且 nano 开启了默认的自动换行（Word Wrap）时，它会在长字符串中间插入一个真正的硬回车（Hard Return）。

在 Bash 的逻辑里，它找不到 $POSTGRES_APP_PASSWO 这个变量（因为后面被回车截断了），于是把它解析为空字符串。最终，数据库真的成功执行了这条 SQL，只不过它执行的是： CREATE USER "app" WITH PASSWORD '';

密码是空的！ 这就是我用正确的密码死活连不上的终极原因。

总结与最佳实践

这三个坑叠在一起，节目效果直接拉满。为了防止自己（或者正在看文章的你）再次踩坑，总结以下几条开发铁律：

终端编辑器防身术： 如果你要在 Linux 终端下用 nano 粘贴长代码或长配置，永远记得带上 -w 参数：
```
nano -w script.sh
```
这会禁用自动换行功能，保命必备。更好的做法是使用 VS Code 的 Remote SSH 插件，直接修改服务器文件，告别终端剪贴板折磨。
环境变量密码规范： .env密码和包含特殊字符的变量，用双引号包起来。行内注释最好另起一行写。
```
# 应用通用密码
PGSQL_APP_PASSWORD="app@pgsql"
```

数据库调试三板斧： 当碰到 Docker DB 密码玄学时，直接在宿主机用超管权限查岗，一秒定音：

# 检查数据库到底吃进去了什么配置
docker exec -it pgsql /bin/bash
echo $POSTGRES_APP_PASSWORD
# 直接用环境变量强制连接测试
PGPASSWORD="$POSTGRES_APP_PASSWORD" psql -h 127.0.0.1 -U app -d postgres

服务器运维就是这样，有时候折磨你两天的并非什么底层内核级 Bug，仅仅是一个看不见的换行符。记录下来，就当是给以后的自己提个醒吧！

全网首发：ColoCrossing 独服踩坑记，用 Docker 优雅征服上古 IPMI 与 KVM 假死

Thu, 02 Apr 2026 21:00:00 +0800

便宜大碗的 ColoCrossing 独立服务器一直备受独立开发者青睐。但当你满怀期待地拿到机器，准备通过 IPMI 挂载 ISO 安装系统时，通常会被现实狠狠地泼一盆冷水——它的底层硬件和 IPMI 管理系统，实在是太老旧了！

翻遍了目前的中文互联网，几乎找不到用现代优雅方式解决这个问题的完整记录。这篇文章记录了我最近在 ColoCrossing 服务器上的一场“受难记”，以及最终如何通过 Docker 实现降维打击的填坑历程。

💥 灾难的开始：现代浏览器与上古协议的冲突

面对基于老旧 Supermicro 主板的 IPMI，我的第一反应是直接用浏览器打开管理地址。然而，噩梦开始了：

现代浏览器早就彻底封杀了不安全的通信协议。无论我是用 Chrome，还是煞有介事地打开 Edge 的 IE 兼容模式，甚至是换用 Firefox，不是“过期的或不安全的 TLS 安全设置”，就是“PR_END_OF_FILE_ERROR”。因为这些老古董 IPMI 使用的是早已被废弃的 TLS 1.0 甚至更古老的弱加密算法。浏览器连登录界面都不让你看。

🌀 越陷越深：IPMIViewer 与 Java Security 地狱

Web 端走不通，那就用官方推荐的方法：下载 IPMIViewer（官方基于 Java 的客户端工具）。

但这引发了第二个深坑。现代版本的本地 JDK 同样对弱加密零容忍。网上的传统教程会教你：找到本地 JDK 目录下的 java.security 文件，把里面禁用的 TLSv1、MD5 等弱加密算法从黑名单里删掉。

我照做了，一顿操作猛如虎，满心欢喜地打开 IPMIViewer 输入 IP 和密码，结果等了半天，直接弹出一个无情的 “Connection failed”。无论怎么调参数、换 Java 版本，就是连不上 KVM 控制台。本地环境被搞得乱七八糟，心态几近崩溃。

🐳 破局之道：Docker 容器化降维打击

在折腾了许久毫无进展后，我意识到：用现代系统去向下兼容上古环境，本身就是一条弯路。 最干净、最优雅的解法是：用 Docker 给它造一个原汁原味的“上古沙盒”。

经过一番搜寻，我找到了一个堪称神器的开源镜像：solarkennedy/ipmi-kvm-docker。这个镜像专门为老旧 IPMI 设计，内置了匹配的 Java 环境和 VNC 桥接。

操作步骤极其简单

只需在任意一台装有 Docker 的机器上（甚至是你的本地电脑）执行以下命令：

docker run -d \
 --name ipmi-kvm \
 -p 8080:8080 \
 solarkennedy/ipmi-kvm-docker

见证奇迹的时刻：

容器启动后，打开你本机的现代浏览器，访问 http://localhost:8080。
此时，你的浏览器里会通过 HTML5 NoVNC 渲染出一个极其清爽的虚拟桌面。
在这个容器提供的浏览器里，输入你 ColoCrossing 服务器的 IPMI IP 地址。在这里，所有的 TLS 协议报错都不复存在。
顺畅登录，点击 Launch KVM，下载 .jnlp 文件并直接在容器内双击运行。
毫无阻碍，KVM 画面瞬间出现！没有 Connection failed，没有任何报错。

用完之后，直接 docker rm -f ipmi-kvm 销毁容器，深藏功与名，宿主机依然一尘不染。

🛑 意料之外的 Boss 战：KVM 画面假死

本以为搞定了 KVM 控制台就可以挂载镜像、一路 Next 安装系统了。结果在尝试安装 Ubuntu 时，我又踩到了最后也是最隐蔽的一个坑。

Ubuntu 的系统引导菜单正常显示，但一敲回车进入安装程序，KVM 画面就瞬间定格，仿佛死机了一样。键盘没反应，无论怎么重新连接 KVM 都没用。

背后的真相是： 当 Ubuntu 等现代系统内核启动，并尝试启用 KMS (Kernel Mode Setting) 切换到高分辨率的现代图形安装界面时，老旧主板上的那颗负责“录制”KVM 画面的底层管理芯片根本无法解码这种高级别/高分辨率的画面，直接“瞎了”。系统其实没死机，还在后台等我点安装，只是我成了盲人。

优雅的解决方案：退守纯文本模式

既然复杂的图形驱动会搞瞎管理芯片，那就彻底放弃图形界面！

放弃死磕 Ubuntu，我果断换用了 Debian 13 (Trixie) 的 ISO。在启动引导菜单中，选择 Command-line install (文本/命令行安装模式)。

Debian 经典的蓝黑相间字符安装界面虽然复古，它极其克制，绝不去触碰底层的复杂显卡驱动。在这个模式下，安装过程异常稳健，行云流水般就完成了磁盘划分（还顺手调教了 LVM 取消了 Swap 分区）和系统安装。

💡 总结与启发

这次 ColoCrossing 的装机之旅可谓一波三折，但也留下了极其宝贵的运维经验：

容器化是跨时代运维的最强武器：面对老旧的硬件和协议，不要试图去降级自己的主力系统，用 Docker 隔离运行特定的上古环境才是正解。
克制即稳定：在老旧服务器上，抛弃花里胡哨的图形安装界面，拥抱纯净的 Debian 文本模式，不仅能避开显卡驱动的暗坑，还能为后期的业务留出最极致的系统资源。

底层基建搭好了，接下来就可以放心跑核心业务了。如果你对后续的高可用架构感兴趣，可以看看我的另一篇实践：《独立开发者的异地灾备实践：PostgreSQL 跨云流复制与全链路 SSL 加固》。

折腾不息，运维不止。祝各位的服务器永不宕机！

从 File Not Found 到一针见血：记一次 Nginx + Docker 路径映射的乌龙与 AI 降维打击

Wed, 18 Mar 2026 10:30:00 +0800

今天为了折腾那套 WordPress 环境，真是差点把键盘给敲烂了。

事情起因很简单：我用 wordpress:6.9-php8.2-fpm 镜像搭了个环境，外面套了一层宿主机的 Nginx 做转发。本以为这种教科书级别的配置，闭着眼睛都能跑通，结果浏览器一刷新，屏幕上冷冰冰地躺着四个大字：“File not found.”。

我反手就是一个 cat 检查了宿主机的权限和文件内容，www-data 用户读写正常，路径也对得上，Nginx 配置里的 fastcgi_pass 更是直连容器端口。这种“文件明明在，但它死活说没有”的感觉，就像是你在兜里摸到了钥匙，但锁却告诉你门没关、只是你手感不对。

这时候，我本着“能问 AI 绝不自己抠脑壳”的原则，先去问了下豆包。结果这哥们儿给我绕了一大圈：先是让我查 Linux 文件权限，接着让我改 Nginx 的 user，最后甚至开始教我怎么重新安装 php-ext-install。折腾了半天，权限改成了 777，镜像重构了好几次，问题依然稳如泰山。那一刻，我真想问问它：你是不是在跟我玩“运维消消乐”？

抱着试一试的心态，我转头把同样的 Nginx 配置和报错丢给了 Gemini。

结果 Gemini 连一句废话都没有，直接点出了那个被我忽略的“盲点”：路径隔离。

我宿主机的 Web 根目录在 /opt/wordpress/html，Nginx 的 $document_root 也是这个。但我忘了，PHP-FPM 是住在 Docker 容器这个“样板间”里的，在它的世界观里，压根就没有 /opt 这个路径。它只认官方镜像默认的 /var/www/html。

当 Nginx 傻乎乎地把 /opt/wordpress/html/index.php 这个路径传给容器里的 FPM 时，FPM 当然只能回敬一句“File not found”。

解决办法简单到想哭：只需要在 fastcgi_param SCRIPT_FILENAME 那里，把 $document_root 换成容器内部的绝对路径 /var/www/html 就可以了。

说实话，这次排障让我感触挺深的。现在的 AI 模型很多，但像 Gemini（哪怕只是 Flash 版本）这样能一眼看穿系统架构逻辑的真的不多。它不是在机械地检索关键词，而是真的理解了“宿主机-容器”这种双重空间下的路径映射逻辑。相比之下，那些只会复读权限指令的 AI，确实显得有些“人工智障”了。

有时候，强大的模型并不在于它能写多长的代码，而在于它能多快定位到那一个让你抓狂的小变量。

最后的小贴士： 如果你也在搞 Nginx 转发 Docker FPM，记住：Nginx 是个传声筒，它说的话（路径），听众（容器）得能听懂才行。

独立开发者的异地灾备实践：PostgreSQL 跨云流复制与全链路 SSL 加固

Sat, 14 Mar 2026 21:00:00 +0800

作为一名独立开发者，最担心的莫过于“单点故障”。虽然 Oracle Cloud 的机器很香，但万一哪天账号被封或机房波动，数据就是命根子。为了实现数据异地实时灾备，我近期完成了一次 PostgreSQL 跨公网的主从同步部署。

这不仅仅是简单的 pg_dump，而是基于流复制（Streaming Replication）的“实时影子库”方案。

1. 需求分析：为什么不直接全量备份？

早期的方案是每天定时跑脚本备份到对象存储，但存在两个痛点：

数据不一致：如果主库在备份间隔内崩掉，会丢失数小时的数据。
恢复慢：紧急情况下，重新拉起容器并还原 TB 级或 GB 级数据的时间成本太高。

我的目标：在另一台 VPS 上维护一个随时待命的只读副本，一旦主库失联，分钟级完成主从切换。

2. 解决方案：流复制 + 双向 SSL 加密

由于数据需要跨越公网传输，安全性是首要考量。

传输层安全：必须开启 SSL，防止数据在公网被嗅探。
身份验证：不使用简单的密码，而是采用 双向证书校验（Cert Authentication）。只有持有我签发的客户端证书的服务器，才有权连接主库进行数据同步。
网络隔离：非标准端口（如 8765）+ 严格的防火墙（iptables/ufw）白名单。

3. 实战避坑指南

坑一：Docker 容器与防火墙的“暗箱操作”

在使用 Docker 暴露端口时，Docker 会自动操作 iptables 规则，导致很多时候即便你没开系统防火墙，端口也是暴露的。

对策：手动在 INPUT 链中通过 -s <备库IP> 锁定来源地址，并持久化规则（iptables-persistent）。

坑二：pg_basebackup 的路径“幽灵”

第一次执行 pg_basebackup 克隆数据时，它生成的 postgresql.auto.conf 会保留当时临时容器的证书路径（比如 /temp_certs）。

对策：克隆完成后，务必手动修正数据目录下的配置文件，将证书路径指向容器启动时的正式挂载路径（如 /var/lib/postgresql/data/certs/）。

坑三：权限！权限！还是权限！

Postgres 对私钥文件的权限极其挑剔。

报错：could not open file "server.key": Permission denied。
对策：在宿主机执行 chown -R 999:999 修正 UID。即便在宿主机看是 root，在容器里必须是 postgres 用户（UID 999）才能读取。

4. 关键配置概览

主库 `pg_hba.conf` 安全策略

# 仅允许 replication_user 通过证书验证进行流复制
hostssl replication replication_user 备库IP/32 cert

备库同步配置 (`postgresql.auto.conf`)

primary_conninfo = 'user=replication_user host=主库IP port=8765 sslmode=verify-ca sslcert=/path/to/client.crt sslkey=/path/to/client.key sslrootcert=/path/to/ca.crt'

5. 迁移与维护的思考

关于数据卷映射，我最终选择了 Bind Mounts（直接路径映射） 而非 Docker Named Volumes。

理由：当需要更换服务器迁移备库时，直接一个 tar 命令打包 /opt/pgsql/data 极其透明。不需要去翻 /var/lib/docker/volumes/ 那些隐秘的哈希目录，迁移效率提升 200%。

最后

高可用架构不是为了炫技，而是为了在意外发生时能睡个好觉。目前这套方案在 Uptime Kuma 的监控下表现稳定，主从延迟几乎保持在 0ms。

美西 VPS 避坑指南：我如何通过 MTR 撕开“假精品线路”的画皮？

Sat, 14 Mar 2026 19:30:00 +0800

缘起：一份并不精品的“精品网”

最近在为生产环境搭建海外 API 网关，对延迟（Latency）和抖动（Jitter）的要求极高。本着“一分钱一分货”的心态，我下单了一家标榜 “美国二区 CN2 GIA 三网直连” 的主机（华纳云活动促销）。

结果，这次经历让我深刻体会到：VPS 厂商的嘴，骗人的鬼。

这篇文章记录了我如何利用 MTR 工具撕开虚假宣传、如何在不同价位的 VPS 间做横向测评，以及最终我是如何成功逼迫厂商原路退款的。

第一章：MTR 才是照妖镜，脚本全是演员

很多新手买完 VPS 喜欢跑个 superspeed 或 KOS 脚本，看到满屏的 AS4809 或 AS9929 就心满意足了。

别天真了。 现在的厂商学精了，他们会针对测速节点做“路由分流”：

脚本测速时：路由精准跳转到精品网出口，给你完美的延迟数据。
业务实际运行时：回程悄悄切换到廉价的 AS4134（电信163） 或 AS4837。

我的鉴定绝招：

不要信任何测速脚本，直接在 VPS 上运行： mtr -znr <你自己家的公网IP> 或 <你业务部署的目标IP>

在这次华纳云的测试中，我抓到了现行：宣传图里明晃晃写着 CN2 GIA 三网直连，可 MTR 回程实测时，发现目标电信服务器时，确实是CN2 GIA路由，可是联通家宽却是 AS10099 -> AS4837，移动更差，直接CMI，这就是所谓的三网直连。这就好比你付了五星级酒店的钱，最后被拉进了快捷酒店。

第二章：四台美西 VPS 横向真实测评

为了找寻最稳的 API 网关，我把手头的几台机器跑了个遍，结果非常有趣：

1. DMIT.io (LAX.Pro) —— 真正的优等生

这是目前美西的“天花板”。

表现：强制三网回程 CN2 GIA。无论是电信、联通还是移动，回程全部强行拉进 59.43 节点。
评价：延迟稳在 150ms，StDev（抖动）极小。贵，但确实是生产环境的首选。

2. Oracle Cloud (美西) —— 令人惊喜的“白嫖”标杆

表现：上游接入 Lumen (Level3) 和 GTT。
评价：电信回程甚至能压到 149ms。虽然没标榜 GIA，但顶级 Tier 1 运营商的互联质量远超普通小厂。适合做高性价比的备份节点。

3. RackNerd (圣何塞) —— 诚实的廉价机

表现：电信/联通走 Arelion 直连，移动走 CMI 但略显拥堵。
评价：它是典型的“偏科生”，联通延迟极佳，移动略拉跨（230ms）。但胜在真实，没在路由上玩猫腻。

4. Dedirock —— 典型的“超售炸裂”

这是一家廉价小厂，MTR 揭露了一个更恐怖的真相：内部超售。

特征：MTR 第一、二步跳到母机网关时，StDev 居然高达 50+。
分析：这意味着母机负载极高，你的数据包还没出门就在宿主机里排队。这种机器，线路再好也做不了 API 业务。

第三章：实战撕逼——如何用 MTR 让虚假宣传原路退款？

很多同学遇到这种“货不对板”往往自认倒霉，或者在工单里只会复读“延迟高”。你要明白，延迟高是主观的，路由不对才是违约。

1. 揪出“文字游戏”的马脚

我这次买的机器，主标题写着 “CN2 GIA 三网直连”，但下单页的线路选择后的一个小问号里才藏着真相，点击后如下图：

商家逻辑： 既然我写了细则，我就没骗你。 我的反击： “CN2 GIA”在行业公约中特指电信 AS4809 全程承载。你用“大标题承诺 GIA，小字分流 CUG”这种展示方式，本身就构成了消费误导。

2. 撕开“针对性优化”的假象

这是最精彩的部分。我发现该服务器存在**“看人下菜碟”**的行为：

脚本测速：跑 KOS 工具箱，联通回程显示为顶级 AS9929。
家宽实测：当我从 VPS MTR 回追我家里的真实公网 IP 时，路径变成了 AS10099 甚至跳到了廉价的 AS4837。

结论很明确： 该商家对已知的机房 IP 段（脚本测速点）开放了高成本路由，而对普通用户 IP 进行了降级。这在 API 网关生产环境下是致命的。

3. 绝杀：礼貌而强硬的退款话术

我给售后工程师发了一段话，大家可以收藏备用：

“我非常认可贵司品牌，但目前的路由交付存在误导：大标题承诺 GIA，实测联通却是降级的 AS10099。且脚本测试与家宽实测存在严重偏差，疑似针对性优化。如果能顺利原路退款，我乐意将其视为选购误解；如果坚持不退，我将不得不带上收集好的 MTR 证据在 HostLoc、V2EX 发布详细测评报告，并向支付网关发起纠纷申诉。我相信贵司更看重长期信誉。”

4. 结局

售后工程师虽然嘴上坚持“线路没问题，是你环境要求高”，但最终还是回复了：“这次特殊帮你申请，原路退回。”

避坑总结： 遇到耍赖的，不要争论好用不好用，要用 “宣传 vs 实测” 的路由差异去打他的脸。

第四章：独立开发者的 API 监控方案

选好机器后，监控也不能掉以轻心。我目前采用的方案：

主服务器：Oracle (API Server)
监控/备机：RackNerd (部署 Uptime Kuma)
Nginx 配置补丁：为了避开 API 的身份验证，直接在 Nginx 层面加一个无害的 /health-check 接口：

location = /health-check {
 access_log off;
 return 200 'Server is Alive';
 add_header Content-Type text/plain;
}

通过 Uptime Kuma 的折线图，我可以随时监控不同线路在晚高峰的抖动情况，真正做到对业务了如指掌。

最后：避坑总结

去程不重要，回程才是爷。
测速脚本会演戏，MTR 永远说真话。
刚出门第一跳第二跳 StDev（抖动） 就很大，说明母机超售严重，趁早搬家。
不要迷信大厂，也不要轻信小厂，跑个监控接口，数据会告诉你答案。

希望大家都能买到心仪的“神机”，远离线路欺诈。