TFS 2017迁移构建系统时NuGet Restore无法访问代理问题求助

我来帮你搞定这个企业防火墙环境下的NuGet代理问题——毕竟在TFS 2017迁移构建系统时，这类网络权限问题太常见了。结合我处理过的类似场景，给你几个可行的解决思路：

1. 给NuGet配置代理参数 #

NuGet本身需要明确代理地址才能穿透企业防火墙，你有两种配置方式：

• 构建机器全局配置：
  直接在运行构建代理的机器上打开命令行，执行以下命令（替换成你的代理服务器地址和端口）：

  nuget config -set http_proxy=http://your-proxy:port
  nuget config -set https_proxy=http://your-proxy:port
  

  如果代理需要账号密码认证，再补充这两句：

  nuget config -set http_proxy.user=your-domain\username
  nuget config -set http_proxy.password=your-password
  

  注意：密码会明文存在NuGet.config里，要是担心安全，要么用加密工具处理，要么用下面的临时配置方式。

• 构建流程临时配置：
  在NuGet Restore步骤前面加一个「Command Line」步骤，运行上面的nuget config命令。这样每次构建都会临时设置代理，不用改动机器的全局配置，更灵活。

2. 检查构建代理的服务账户权限 #

TFS构建代理是用特定账户运行的，这个账户得有通过防火墙访问代理服务器的权限：

• 确认构建代理的运行账户（比如Network Service或者你的域账户）被企业防火墙规则允许访问NuGet源（不管是nuget.org还是内部私有源）。
• 如果代理用NTLM认证，得确保这个账户有对应的访问权限，并且NuGet的代理用户配置里填的是正确的域账户信息。

3. 给TFS构建代理本身配置全局代理 #

TFS 2017的构建代理可以全局设置代理，让所有构建步骤都用这个代理走流量：

• 登录TFS管理控制台，找到「代理池」，选中你的构建代理进入配置页面。
• 在代理设置里找到「代理」选项，填入企业代理的地址、端口，还有认证信息（如果需要的话）。
• 保存后重启构建代理服务，让设置生效。

4. 手动验证NuGet源的可访问性 #

有时候问题不一定是代理配置，而是源本身在机器上没法访问：

• 直接在构建机器上打开命令行，运行nuget restore YourTestProject.csproj，看看能不能成功还原。如果手动都失败，那就是网络/代理的问题，和构建流程无关。
• 也可以用浏览器访问NuGet源的地址（比如https://api.nuget.org/v3/index.json），确认能不能通过代理打开。

5. 切换到内部私有NuGet源 #

如果外部源访问实在麻烦，不如在企业内部搭个私有NuGet源（比如用NuGet.Server或者类似工具），把项目需要的包同步到内部源，然后在项目的NuGet.config里指向这个内部源：

<configuration>
  <packageSources>
    <add key="InternalNuGetRepo" value="http://your-internal-nuget-server/v3/index.json" />
  </packageSources>
</configuration>

这样就不用访问外部网络了，也避开了代理问题。

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