Artifactory从5.2.0升级至5.10.2后远程仓库报Proxy Error 407

这种跨小版本升级后突然出现的代理认证失败问题，大概率是新版本对代理配置的处理逻辑做了调整，结合你提供的信息，我整理了几个重点排查方向：

• 检查代理认证方式的匹配性
  Artifactory 5.10.x对代理认证的处理比5.2.x更严格，尤其是NTLM认证场景。确认你在全局代理配置里选的认证类型（Basic/NTLM）和代理服务器要求的一致：

  • 如果是NTLM认证，务必填写Domain字段——5.2.x可能默认使用当前服务器域，但5.10.2需要明确配置；
  • 如果是Basic认证，尝试重新输入代理账号密码（注意是否有空格或大小写错误），有些情况下升级会导致凭证的加密存储异常。

• 排查仓库级代理的覆盖设置
  即使全局代理已正确配置，个别远程仓库可能开启了Override Global Proxy选项，导致使用了错误的代理配置。逐个检查远程仓库的Proxy标签页，确认要么继承全局代理，要么自定义的代理信息完全正确。

• 深挖核心日志的详细错误
  你提供的UI测试请求日志：

  20180419151212|30|REQUEST|172.22.50.135|usertst|POST|/ui/admin/repositories/testremote|HTTP/1.1|400|1610
  只是前端请求的错误，无法反映代理交互的真实问题。去$ARTIFACTORY_HOME/logs目录下查看artifactory.log或artifactory-request.log，找到包含Proxy Error 407的条目，里面通常会有类似Proxy Authentication Required的具体提示，能帮你定位是凭证无效、认证方式不支持还是代理服务器拒绝请求。

• 模拟请求验证代理兼容性
  用curl模拟Artifactory的请求逻辑，测试代理服务器是否能正常通过认证：

  curl -x http://你的代理主机:端口 -U 代理账号:代理密码 https://目标远程仓库地址
  

  如果curl能成功访问，说明是Artifactory的请求头或代理传递逻辑有问题；如果curl也失败，那问题出在代理服务器本身（比如账号权限变更、IP白名单限制等）。

• 检查JVM级代理属性配置
  5.10.2可能需要额外配置JVM层面的代理属性，确保代理凭证能正确传递到底层HTTP客户端。在Artifactory的启动脚本（比如$ARTIFACTORY_HOME/bin/artifactory.default）里添加以下配置：

  export JAVA_OPTIONS="$JAVA_OPTIONS -Dhttp.proxyHost=你的代理主机 -Dhttp.proxyPort=代理端口 -Dhttp.proxyUser=代理账号 -Dhttp.proxyPassword=代理密码"
  export JAVA_OPTIONS="$JAVA_OPTIONS -Dhttps.proxyHost=你的代理主机 -Dhttps.proxyPort=代理端口 -Dhttps.proxyUser=代理账号 -Dhttps.proxyPassword=代理密码"
  

  添加后重启Artifactory，再测试连接。

• 处理凭证中的特殊字符
  如果代理密码包含特殊字符（比如@、#、&等），5.2.x可能能自动处理，但5.10.2需要对密码进行URL编码。比如把@换成%40，#换成%23，再重新配置代理密码测试。

• 验证配置文件的完整性
  升级过程中可能存在配置文件迁移不完整的情况，对比旧版本（5.2.0）的$ARTIFACTORY_HOME/etc/artifactory.config.xml，检查<proxies>节点下的配置是否完整，重点关注authType、username、password、domain等字段是否和旧版本一致。

内容的提问来源于stack exchange，提问作者J. Doe