RHEL7下配置Subuid/Subgid后Podman构建镜像无法拉取Alpine报错

该报错和已完成的Subuid/Subgid配置完全无关。Podman构建流程第一步需要拉取alpine基础镜像时，会按照/etc/containers/registries.conf定义的仓库搜索顺序，逐一向所有候选registry发起拉取请求，本次报错就是所有候选仓库全部连通失败导致的：

• 排在搜索优先级第一位的localhost本地registry未部署对应服务，443端口无监听，直接触发连接拒绝
• 后续配置的红帽官方公共仓库、Docker Hub 公共仓库均出现TCP连接被对端重置，属于网络层无法和目标registry正常建立连接的问题

1. 修正registry配置无效项 #

编辑/etc/containers/registries.conf检查配置内容：

• 核对unqualified-search-registries列表内的所有条目，移除拼写错误、未标注正确访问端口的无效地址
• 如果从未部署本地镜像仓库，直接删除列表中指向localhost的搜索条目，避免无意义的本地探测增加报错日志

2. 解决外部仓库连通性问题 #

针对所有公网registry连接重置的场景，根据实际网络环境选择适配方案：

• 为Podman配置符合内网访问规则的代理：在系统全局环境变量中配置http_proxy、https_proxy参数，让Podman进程通过代理链路访问外部公共registry
• 替换搜索源为内网自建镜像缓存：如果内网有统一的镜像代理服务，直接把该服务地址加到unqualified-search-registries列表的最高优先级位置，跳过直接访问公网的环节
• 拆分验证流程：不要依赖build流程的隐式镜像拉取，单独执行podman pull alpine命令，逐个确认每个搜索仓库的连通状态

3. 临时测试绕开多仓库搜索逻辑 #

如果临时需要完成构建验证，可以在Dockerfile的FROM行直接填写可正常访问的完整镜像路径，绕开Podman的无别名多仓库搜索逻辑，将原简写的alpine替换为有效完整镜像地址后，再重新执行构建命令。

注意：RHEL7自带的Podman为1.x稳定版本，配置语法和后续新版本存在差异，修改完配置后可执行podman info确认配置是否被正常加载识别。

内容的提问来源于stack exchange，提问作者user804401