那晚我从八点折腾到凌晨一点，就为了一个 502

那晚我从八点折腾到凌晨一点，中间有大概两小时是在错误的方向上找。

起因就是浏览器上一句话：

当前无法处理此请求。
HTTP ERROR 502

那天是我把本地跑通的东西搬到腾讯云 Ubuntu 服务器的第一天。

我第一反应是去看应用日志。日志里有一行：

Starting WebUI at http://0.0.0.0:6185

服务是起来的。这行我看了好几遍也没意识到它在告诉我什么——容器里的服务是好的，问题在"外面的人怎么进来"这一段。我却一直在容器里面翻。

后来我改了个顺序，从外往里查，十分钟就通了。

先查端口映射。我这次是用 docker run 手动起的服务，忘了加 -p：

docker port astrbot
# （空输出）

空的。容器内部的 6185 和宿主机的 6185 是两回事，没映射，宿主机的端口就是个空门。

docker run -d --name astrbot -p 6185:6185 ...

还是不通。接着查云平台那道门。服务器里我也补了一条（顺手把本机规矩理顺）：

iptables -I INPUT -p tcp --dport 6185 -j ACCEPT

但更重要的是去腾讯云控制台的防火墙，把用到的端口都放行：后台 6185、AstrBot 和 NapCat 通信的 6195、NapCat 面板 6099。

这里有个容易忽视的地方：服务器里 ss -tlnp 明明显示在监听，外面却永远连不上，那就是云平台的规则没放。本机的 iptables 管不了云平台。

最后一段是容器网络。前面都通了之后，NapCat 还是连不上 AstrBot：

getaddrinfo EAI_AGAIN astrbot

因为我用 docker run 单独起的容器不在 compose 那张网里，服务名解析不了。回到 compose 统一管理就好了。

在这中间还夹了一件小事。我能打开登录页了，但用教程里的默认密码进不去。翻启动日志才看到：

Login failed ... random strong password printed in the startup logs

新版把初始密码改成了随机强密码，只打印在启动日志里，不在文档里：

docker logs astrbot 2>&1 | grep -i password

拿到之后第一件事就是改掉。

那天之后我固定按这个顺序查"网站打不开"：先 docker port 看映射，再看云平台防火墙的入站规则，最后看容器网络能不能互相解析。

顺序本身比命令重要。我那天卡住的不是不会敲命令，是先往应用层里钻了，方向错了，敲多少命令都是白搭。