Docker API 网关配好 HTTPS 后，为什么 IP 端口还能直连？

给 Docker API 网关绑定域名、装好证书后，浏览器出现 HTTPS，并不代表所有访问都经过了反向代理。如果旧的 服务器IP:3000 仍可从外网访问，调用者可能绕过代理层的访问限制和日志；后端自身有鉴权，也不能把这条未受同样控制的入口当作已经关闭。

本文面向维护自建网关的人，检查“公网域名 → HTTPS 反向代理 → 网关容器”这段入口。采用普通 Docker bridge 网络；host、macvlan、直接路由及其他特殊网络要另行核对。3000 只是示例端口，不代表任何网关项目的默认设置。本文不替你修改生产环境，也不把本地模拟当成真实部署验收。

1. 先确定反向代理运行在哪里

把域名、代理所在环境、网关服务名、容器内监听端口和宿主机发布端口写在同一张表里。最常见的两种部署需要不同的后端地址：

第二行中的 gateway 必须是实际服务名，3000 必须是容器内端口。同一 Compose 网络支持按服务名发现服务；容器重建后 IP 可能变化，因此不要把临时容器 IP 写死。[2] 代理容器中的 127.0.0.1 通常指代理容器本身，不是宿主机或另一个容器。

网关进程还必须在容器内可被代理访问的接口上监听。只监听网关容器自己的回环地址，可能导致同网络的代理仍然连不上。容器内监听所有接口与发布到宿主机公网接口是两个不同动作；前者也意味着同网络其他容器可能访问它，因此不要把无关、不受信任的容器加入这个网络。

2. 关闭不需要的后端公网入口

检查实际运行容器的端口绑定，同时检查部署文件。只改文件而没更新容器，运行状态不会自动变成新配置。

普通端口映射 3000:3000 没有限定宿主机地址，不能理解为“只有本机能用”。Docker 官方明确提醒，发布端口默认可能对外开放。[1] 若代理就在宿主机，可将这项映射改为带地址的 127.0.0.1:3000:3000；若代理与网关在同一受控容器网络，通常直接移除网关服务的宿主机端口发布，让代理通过服务名连接。保留代理自身所需的公网入口。

操作前先确认还有可靠的管理路径，保存旧配置并安排可接受的中断窗口。更新容器后重新查看实际绑定；不是只重启应用进程。使用多个 Compose 文件时，要检查最终合并配置是否仍保留旧的公网映射，不能因为新文件多了一条回环映射就认定旧映射已消失。

这里还有三个容易漏掉的边界：

• IPv4 与 IPv6 分别检查。没有指定宿主机 IP 的映射，在某些 Docker 配置中也可能通过宿主机 IPv6 地址转发；只测 IPv4 不够。[1]
• Docker 官方记录：早于 28.0.0 的版本存在同一二层网络主机能够访问 localhost 发布端口的问题。旧版部署不要只靠回环绑定下结论，应升级到受支持版本并做外部验证。[1]
• Linux 上不能只凭“ufw 已拒绝 3000”认定 Docker 端口不可达。Docker 文档说明，其端口转发处理可能先于 ufw 常用规则发生。[3] 应优先去掉不必要的端口发布，再按所用 Docker 防火墙后端检查有效规则及云安全组，不要通过关闭 Docker 防火墙功能来试错。

移除宿主机发布并不隔离宿主机管理员或同网络容器；特殊直接路由配置也会改变可达范围。此处的目标是收紧不需要的外部访问，不是宣称容器已经成为完全隔离的安全边界。

3. 验收 HTTPS 时保留两段链路的区别

公网客户端连到反向代理的 HTTPS，与代理连到网关的连接，必须分别确认。前一段证书有效，不证明后一段也已加密；仅在明确受控的同机网络内考虑内部 HTTP，跨不可信网络时使用经过验证的 TLS 或经过认证的加密通道。

若使用 Caddy 的常见公网域名自动 HTTPS 部署，先核对域名的 A/AAAA 记录是否指向正确服务器，外部验证流量能否到达代理，代理能否绑定相应端口，以及证书数据目录是否可写并持久保存。[4] 默认常见流程涉及 80/443；DNS challenge 等其他验证方式有自己的配置条件，不是所有方案都必须按相同方式开放 80。证书续期依赖的条件不能在首次签发后被撤掉。

不要遗漏错误的 AAAA 记录：IPv4 正常、IPv6 指向旧机器时，部分客户端仍会失败。用域名验证证书覆盖范围，不要把 IP 地址上的证书不匹配当作“端口已关闭”，也不要加入关闭证书验证的选项来让测试通过。

客户端应直接配置经过确认的 HTTPS API 入口。HTTP 自动跳转不能保护已经发往 HTTP 的 Authorization 或正文；不要先带真实密钥请求 HTTP，再指望跳转补救。已有证书错误可参考证书验证排查，不必在这里重新调整模型参数。

4. 从外部做一次无凭证、有限时的检查

从一台有权测试、且不在该宿主机上的设备检查域名入口，再检查旧的宿主机后端端口。这里只访问你控制的地址，不扫描第三方网络。先选定一个文档确认的、只读且不会触发生成的诊断路径；下例 /healthz 是占位路径，必须替换，不能假设每个网关都有它。

Windows PowerShell 示例：

curl.exe -q --silent --show-error --connect-timeout 3 --max-time 10 --output NUL --write-out "http=%{http_code}\n" https://api.example.com/healthz

将域名和路径换成自己的已确认目标。Linux/macOS 使用 curl，将 NUL 换成 /dev/null。-q 放在首个参数，避免自动载入个人 curl 配置中的附加选项；命令不附带 Key、Cookie 或请求正文，不自动跟随跳转，也不自动重试。连接阶段最多 3 秒，总请求最多 10 秒，HTTPS 保持默认的证书验证。[5] 企业网络的既有代理仍可能影响路径，记录测试设备和代理环境，不擅自绕过组织网络策略。

测试旧后端时，只把目标替换为你确认曾发布过的地址、协议和安全路径，例如原来使用 HTTP 的宿主机端口。绝不为“测是否能通”添加真实凭证。IPv6 地址写入 URL 时需要方括号。分别记录域名入口、IPv4 后端入口和适用的 IPv6 后端入口的结果。

此命令未使用 --fail，HTTP 4xx/5xx 也可能对应 curl 退出码 0，所以要同时看 http= 和错误输出。http=000 只是没有取得正常 HTTP 响应的线索，DNS、TLS、连接或超时都可能导致它。不要把“curl 没报错”当成服务健康，也不要把“没有 200”当成端口封闭。

文中命令已用本机模拟 HTTP 服务检查正常状态、错误状态、重定向不跟随、连接拒绝和超时，并检查请求未携带 Authorization、Cookie 或正文。该模拟没有验证公网证书、真实 Docker 防火墙或任何供应商模型，也没有调用付费 API。

5. 容器重建后再做一轮验收

先确认反向代理可达后端，再关闭旧入口，完成外部复核。若失败，回滚应恢复经过审查的上一版配置；不要临时把后端放回公网并关闭鉴权“救急”。涉及网关数据的升级，另按备份与恢复演练准备。

验收记录至少包含：北京时间、Docker 与代理版本、网络模式、实际端口绑定、测试来源、IPv4/IPv6 结果，以及代理和网关日志中的对应请求。记录中不包含密钥或完整用户输入。

上线前逐项确认：

1. 域名证书与预期主机名匹配，续期所需路径及证书存储保持有效。
2. 代理可以到达网关；外部来源不能绕过预定入口直达后端端口。
3. 对需要鉴权的接口，无凭证或错误凭证按预期被拒绝。健康检查公开返回 200 不代表鉴权失效；鉴权测试也不等于“关闭直连端口”的网络测试。
4. 经确认不会转发到付费上游的模拟路由，能分别完成普通响应和流式响应。实际模型能力需要独立、受控的验收，不能由健康检查替代。
5. 重建后重新核对端口绑定、服务名解析、证书存储和外部访问结果。部署文件与运行状态一致，而不只是当前手动修改暂时有效。

若普通请求正常、流式输出异常，继续看流式响应排查。这轮检查解决的是入口、连接与访问边界，不证明模型质量或计费正确。

官方资料与适用范围

1. Docker：Port publishing and mapping。核对发布地址、IPv6、旧版 localhost 限制与直接路由边界。
2. Docker Compose：Networking。核对服务名、容器内端口和重建后的地址变化。
3. Docker：Packet filtering and firewalls。核对 Docker 与 ufw 的规则处理差异。
4. Caddy：Automatic HTTPS。核对域名、端口、存储与证书管理条件。
5. curl 官方命令手册。核对配置加载、超时与状态码输出。

资料核对日期：2026-10-20。Docker 文档网页在本次环境中连接失败，相关内容通过 Docker 官方文档仓库的对应 Markdown 核对。不同网络驱动、防火墙后端和托管代理需按实际版本复查；本文没有执行真实生产部署。