docker compose网络别名是同一自定义网络内服务间基于dns的逻辑主机名映射，仅在声明的网络中生效，不跨网传播，支持多别名、中性命名与分层隔离，但本身不提供安全防护。
别名本身不提供安全防护，但合理使用能降低网络拓扑暴露风险。关键在于避免让容器通过服务名反推整体编排结构，同时限制可解析名称的范围和语义。
只在必要网络中声明别名
别名仅在其所属的自定义网络内生效，不会跨网络传播。若服务只需被 frontend 网络中的容器访问，就不要把它加入 backend 或 database 网络，更不要在这些网络里配别名。
- 每个服务只连接它真正需要通信的网络，减少 DNS 暴露面
- 删除默认 bridge 网络（除非明确需要），因其不支持别名且易被误用
- 例如：数据库服务 db 仅接入 db-network，且只在该网络设别名 db-primary；绝不把它加进 frontend 网络或设 www 或 api 等误导性别名
使用中性、无拓扑含义的别名
避免使用暴露部署意图的名称，比如 cluster-01、master、leader、v2、staging 等。攻击者可能通过这些别名推测服务角色、版本或高可用结构。
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 优先选用功能导向、环境无关的名称：auth-gateway、cache-bus、event-sink
- 禁用带序号、环境标识、架构层级的别名（如 api-v1、backend-prod、redis-slave-2）
- 同一服务在不同网络中可设不同别名，例如在测试网用 test-db，在生产网用 core-storage
禁用默认服务名解析（可选加固）
Docker 默认允许容器通过服务名（如 web、db）直接访问——这本身就是最明显的拓扑线索。可通过覆盖容器内 /etc/hosts 或使用自定义 DNS 策略来屏蔽该行为。
- 在应用启动脚本中移除 /etc/hosts 中由 Docker 自动生成的服务名条目
- 用 --dns 自定义 DNS 服务器，并配置其仅响应已声明的别名，拒绝解析原始服务名
- 或在 compose 文件中为服务显式设置 hostname: "" 并配合 domainname: "internal"，使容器内 hostname 不再等同于服务名
结合网络隔离与别名分层
用多网络划分通信域，再为同一服务在不同网络中分配不同别名，实现逻辑隔离。
- 例：web 服务接入 ingress-network（别名：router）和 app-network（别名：ui-core）
- backend 服务只接入 app-network（别名：api-service），不暴露在 ingress-network 中
- 这样即使某个容器被攻陷，它也只能通过 router 访问 web，无法通过服务名反查出 backend 存在，也看不到 db 或 cache 的任何别名
