适用范围：先确认是联网失败还是依赖问题

本文面向 Windows、macOS、Linux 上使用 .NET SDK 命令行和 PackageReference 的项目，所用 list source 与 restore 基本命令按 Microsoft 标注的 .NET 6 SDK 及后续版本文档核对。旧版 Visual Studio、nuget.exe 和 packages.config 项目应按其对应入口处理，不能照搬所有命令。只操作自己信任的项目；还原会联网、写包缓存和项目中间文件，也可能运行项目定义的 MSBuild 目标，通常不需要管理员权限。

看到的结果下一步
无法读取服务索引、解析失败或连接超时记录包源主机名及内层错误，查代理与网络
401、403 或登录提示查该包源的账号授权、凭据提供程序或组织策略
找不到指定包或版本查源地址、启用状态、源映射和版本是否存在
TLS 或包签名校验错误区分 HTTPS 证书链与包签名信任，保留原始错误
还原成功但构建失败继续查编译和项目配置，不据此判定网络故障

第一步：在相同项目目录记录包源和失败请求

Windows PowerShell / macOS / Linux；在项目目录执行，MyApp.csproj 换成真实路径
dotnet --version
dotnet nuget list source --format Detailed
dotnet restore ./MyApp.csproj --verbosity normal
  1. 确认列出的 SDK 版本与项目要求一致；将原来失败的同一个项目路径传给 restore，不在另一个目录测试后直接对比。
  2. 记录包源列表中启用的源、失败主机名、HTTP 状态或内层连接错误。需要更多信息时仅将 verbosity 改为 diagnostic，在本地查看后截取脱敏片段。
  3. 浏览器登录过某个私有源，不等于终端已有相同身份。不要复制浏览器会话、完整认证 URL 或未经脱敏的诊断日志来求助。

第二步：先核对配置继承，再考虑更换包源

未指定 --configfile 时，命令会按当前目录读取配置层级。仓库或上级目录中的 NuGet.Config 可能改变包源；packageSources 下的 clear 会清除该节点继承的条目。还要检查 disabledPackageSources 与 packageSourceMapping，不能只看配置文件里有没有 nuget.org 字样。

如果用 --configfile 指向一份文件，官方说明是只使用这份文件的设置。拿仅含代理的临时文件测试，可能同时丢掉原来的私有包源、认证和源映射；这不是单变量网络对照。先用下面命令比较指定文件的源列表，需要的企业配置由维护者确认。

只读列出指定配置中的源；路径替换为实际文件
dotnet nuget list source --configfile ./NuGet.Config --format Detailed

第三步：用一次临时 HTTP 代理对照

先在代理客户端确认真实 HTTP 或 mixed 监听端口及服务状态。下例 7890 是占位值，127.0.0.1 是运行 dotnet 的这台机器，不能照搬到容器或远程终端。NuGet 官方支持 http_proxy 和 no_proxy 环境变量；同时检查 NuGet.Config 中是否已有 http_proxy 设置。不要叠加两套矛盾配置后猜优先级。

macOS / Linux 的 Bash 或 zsh；变量仅作用于这次命令，无需 sudo
http_proxy=http://127.0.0.1:7890 dotnet restore ./MyApp.csproj --verbosity normal
Windows PowerShell；保存并恢复当前进程变量，不写系统环境变量
$roxiOldNugetProxy = $env:http_proxy
try {
  $env:http_proxy = 'http://127.0.0.1:7890'
  dotnet restore ./MyApp.csproj --verbosity normal
} finally {
  if ($null -eq $roxiOldNugetProxy) {
    Remove-Item Env:http_proxy -ErrorAction SilentlyContinue
  } else {
    $env:http_proxy = $roxiOldNugetProxy
  }
}

如果已有 no_proxy，确认失败的公网源是否被列入绕过范围，同时保留企业内网必须直连的域名。每次只改变一个因素，比较同一失败请求，并观察客户端连接记录。已有缓存的包可能无需下载，因此“本次还原成功”不能单独证明全部网络请求经过代理。

认证和证书问题各自处理

  1. 私有源需要交互认证且已配置正确的凭据提供程序时，可在可信项目中使用 dotnet restore ./MyApp.csproj --interactive；它只是允许等待用户操作，不会自动取得缺少的权限。
  2. 收到证书错误时，核对系统时间与组织提供的可信证书部署说明。不要给包源关闭 TLS 校验，也不要把未知证书当成代理的必要配置。
  3. 只有多项目并发时失败，可单次加 --disable-parallel 作对照；它关闭的是多个项目并行还原，不是“所有 HTTP 请求串行”。

验收与回退：看实际依赖是否恢复

  1. 再次对原项目执行还原，确认退出结果和具体包源错误消失；PackageReference 项目通常会生成 obj/project.assets.json。文件存在不等于项目已经构建成功。
  2. 在可信项目中按原开发流程构建，区分网络恢复与编译成功；核对项目文件和已有 packages.lock.json 是否出现非预期变化。有锁文件且团队要求固定版本时，可使用 --locked-mode 禁止更新锁文件。
  3. 临时环境变量已随命令结束或 finally 恢复。若改了配置文件，仅撤销本轮改动并重新列出包源；不要清空所有缓存或删除依赖声明来掩盖问题。仍失败时保留 SDK 版本、源主机名、内层错误及对照条件。