Pulumi项目由通用编程语言编写，但一次pulumi preview或up可能同时访问状态Backend、下载Resource Plugin、安装语言依赖，并调用AWS、Azure、Google Cloud或Kubernetes API。一个代理变量能否覆盖这些请求，取决于实际进程和工具。
Pulumi的四类外部依赖
| 对象 | 用途 | 配置重点 |
|---|---|---|
| Pulumi Backend | 登录、状态、历史与协作 | Backend地址、代理、Token与CA |
| Resource Plugin | 管理云和平台资源 | 插件下载、版本与校验 |
| 云Provider API | 读取与修改资源 | 区域、凭据、代理和私有端点 |
| 语言依赖 | Node、Python、Go、.NET等包 | 各包管理器的源、代理与证书 |
先确认使用哪种Backend
项目可使用托管服务或支持的自托管/本地Backend。Backend决定状态与登录请求的目标，不等于云Provider端点。诊断时记录Backend类型和主机，但不要公开Access Token、状态内容和Stack配置秘密。
Backend正常为何云资源仍读取失败
Pulumi CLI连接Backend后，Provider Plugin还要访问云API。云凭据、区域、Private Endpoint和组织代理策略可能完全不同。应从错误中提取服务与主机，并用最小权限的只读调用验证，而不是反复重新登录Pulumi。
插件下载在哪个进程中发生
Resource Plugin通常由Pulumi CLI管理并存入用户目录或缓存。CI临时节点若没有缓存，需要访问插件分发位置。开发机已经安装插件，会掩盖CI网络故障。插件来源和校验应保持受控，不要随意从未知镜像复制二进制文件。
语言包管理器为何要单独配置
TypeScript项目可能调用npm、pnpm或Yarn，Python项目使用pip，.NET使用NuGet。它们不会自动共享Pulumi CLI设置。对应排查可参考npm、pnpm和Yarn代理配置及pip与PyPI代理配置。
NO_PROXY如何处理私有资源
自托管Backend、Kubernetes API、云私有端点和链路本地元数据服务可能应直连。绕过规则需按每个客户端的语法验证，不能假定Node、Python、Go和Provider Plugin解释一致。过宽规则还可能让公共云API绕过组织出口。
Provider凭据与Pulumi Token有何区别
Pulumi Backend Token用于状态服务身份；云Provider凭据用于管理实际资源；代理凭据用于网络出口。三类秘密应分别存储、轮换和授权。不要把云密钥写入Stack普通配置，敏感值应使用Pulumi秘密能力或外部秘密系统。
证书错误在哪一层修复
CLI、语言运行时和Provider Plugin可能使用不同CA来源。自托管Backend证书、企业代理CA和云私有端点证书也各自独立。修复实际失败进程的信任链，而不是全局关闭TLS校验。
Preview和Up的网络行为有什么不同
Preview通常会读取状态和云端现状，并执行数据源查询；Up还会创建、修改或删除资源。网络验证优先在隔离Stack和最小权限下使用Preview，但不能把它绝对视为无外部调用。正式Up前审查计划、目标Stack和变更范围。
代理中断后的重试风险
资源创建请求超时后，Provider未必知道云端是否已经创建成功。Pulumi会在后续刷新或更新中协调状态，但运维人员不应手工连续重跑。先查看云端资源、Stack状态与操作记录，避免产生重复资源。
CI排查顺序
- 记录Pulumi、语言运行时与Provider版本；
- 识别失败目标是Backend、插件、包源还是云API；
- 检查CI进程代理、NO_PROXY与CA；
- 区分代理407、Backend身份和云权限；
- 使用隔离Stack和最小权限Preview；
- 核对超时后云端与状态的一致性；
- 清理调试Token、状态输出和详细日志。
结论
Pulumi代理配置需要按Backend、插件、语言依赖和云Provider拆分。先识别失败服务，再修复对应进程和凭据，才能避免将网络故障误处理成状态或资源变更问题。
