docker网络别名本身不防劫持，而是通过“别名+网络分层+语义脱敏”构建防御纵深：①仅在必需网络声明别名；②用中性无含义别名；③禁用默认服务名解析；④按通信域分层设别名。
Docker 网络别名本身不直接防范服务劫持，它也不是一种安全控制机制，而是一种服务发现辅助手段。但合理设计别名配合网络隔离，能显著缩小攻击面、混淆拓扑结构、阻断基于服务名的横向探测路径，从而间接提升抗劫持能力。关键不是“用别名防劫持”，而是“用别名+网络分层+语义脱敏”构建防御纵深。
以下四点是真正起效的核心实践：
只在必需网络中声明别名，严格限制 DNS 暴露范围
别名仅在其所属自定义网络内生效，跨网不可解析。若数据库服务只需被后端应用访问，就：
- 不把它加入 frontend 或 public 网络
- 不在这些网络中配置任何别名（哪怕只是测试用的 test-db）
- 删除所有服务对默认 bridge 网络的隐式依赖（禁用
network_mode: "bridge"）
这样，即使前端容器被攻陷，也无法通过ping db或nslookup cache发现后端服务存在。
使用中性、无角色/版本/序号含义的别名
避免暴露部署意图，防止攻击者反推架构：
- ❌ 不要用：
redis-master、api-v2、backend-prod、cluster-03 - ✅ 推荐用：
auth-bus、session-store、event-ingest、config-sink
同一服务在不同环境可设不同别名（如测试网用test-cache，生产网用core-cache），但名称本身不泄露层级或状态。
禁用默认服务名解析，切断最直接的拓扑线索
Docker 默认允许容器通过 http://db 直连——这是最易被利用的拓扑指纹。加固方式包括：
- 在容器启动脚本中删除
/etc/hosts里由 Docker 自动生成的服务名条目（如172.20.0.3 db） - 使用
--dns指向自定义 DNS 服务，并配置其仅响应已声明的别名，拒绝解析原始服务名（如db、web） - 为服务显式设置
hostname: ""和domainname: "internal"，使容器内hostname不再等同于服务名，干扰脚本自动探测
按通信域分层设别名，实现逻辑隔离
用多个网络划分职责，再为同一服务在不同网络中分配不同别名：
-
ingress-network中，web 服务别名为router（面向外部流量） -
app-network中，web 服务别名为ui-core，backend 服务别名为api-service -
data-network中，db 服务别名为storage-node，cache 服务别名为fast-cache
此时，一个被入侵的 ingress 容器只能看到router，完全无法解析api-service或storage-node，也看不到其他服务的真实命名关系。
不复杂但容易忽略
