Podman与Docker在命令体验上相似，架构却不完全相同。Podman可以无守护进程运行，也常以Rootless用户身份管理容器；API服务可能由用户级systemd启动。镜像拉取、Buildah构建和容器内应用仍是不同网络阶段。
Podman中的四个代理边界
| 阶段 | 请求来源 | 重点检查 |
|---|---|---|
| podman pull | 当前Podman进程或服务 | 用户环境、Registry、认证与CA |
| Buildah构建 | 构建进程和RUN步骤 | 构建变量、秘密和镜像层 |
| 运行容器 | 容器内应用 | 容器环境、DNS、NO_PROXY与CA |
| Podman API服务 | 用户或系统服务 | systemd环境和长期进程 |
Rootless为何要看运行用户
Rootless Podman使用当前用户的配置目录、存储和用户级服务。管理员给系统级服务设置代理，未必影响普通用户。排查时记录podman info中的Rootless状态、运行账号、环境和服务方式，避免在错误配置目录修改。
镜像拉取与容器联网不是一回事
podman pull访问Registry API、Token和Blob；启动后的容器访问业务API或包仓库。前者成功，只能证明Podman进程到Registry可达。Registry链路可参考Docker Registry认证、Blob与代理排查。
Buildah构建如何避免泄露代理密码
构建阶段可按需要传递代理变量，但不要把带密码的ENV永久写进Containerfile，也不要让凭据留在构建历史、缓存层和日志。优先使用受支持的秘密挂载或临时环境，并在最终镜像检查残留。
NO_PROXY为什么每层都要验证
宿主Podman进程、构建RUN命令和容器应用可能使用不同网络库。相同NO_PROXY字符串对域名后缀、端口、CIDR和IPv6的解释也可能不同。内部Registry、宿主服务和容器网络地址应逐项验证。
Rootless网络为何与宿主不同
Rootless容器常使用用户态网络组件，localhost、宿主地址、端口映射和IPv6行为与Rootful模式可能不同。宿主能访问的私网地址，容器不一定有相同路由。应在容器内执行最小DNS和连接测试。
用户级systemd服务如何更新
如果Podman API或容器由用户级systemd管理，应在用户服务的drop-in或EnvironmentFile中配置代理，执行用户级daemon-reload并重启。登录Shell的变量不会自动修改已运行服务。
证书与私有Registry
私有Registry应使用正确域名和受信CA。Rootless用户与系统服务读取的证书目录可能不同，应按Podman当前版本支持配置。不要通过标记不安全Registry长期绕过TLS。
407、401和拉取失败怎样区分
- 407：企业正向代理认证；
- 401/403：Registry登录和仓库权限；
- manifest unknown：标签、平台或清单不存在；
- x509错误：CA、域名或系统时间；
- 容器内超时：容器网络、DNS、代理或应用配置。
代理切换后为何旧容器不变
容器启动时获得环境和网络配置。修改宿主环境不会自动更新已有容器，应按编排方式重新创建。应用内部还有连接池，重建容器前需处理在途任务并确保可回滚。
排查清单
- 记录Podman、Buildah版本和Rootless状态；
- 确定失败在pull、build、run还是API服务；
- 检查对应用户和进程的代理与CA；
- 区分407、Registry权限、TLS和容器DNS；
- 验证构建秘密未进入镜像层；
- 重新创建容器并核对出口；
- 检查Rootless端口和存储权限。
结论
Podman代理配置要以Rootless用户和具体阶段为中心。拉取、构建、运行与API服务分别验证，才能避免把Docker守护进程经验机械套用到不同架构。
