记一次 Maven 3.8.3 无法下载 HTTP 仓库依赖的排查历程

问题背景

在日常开发中，我们项目组使用内部搭建的 Nexus 仓库管理依赖，仓库地址为：

http://nexus.xxx.local/repository/idmp-maven-thirdparty/

某天在升级开发环境时，我将 Maven 从 3.6.3 升级到 3.8.3，随后便遭遇了诡异的依赖下载失败问题。

问题现象

执行 mvn clean install 时出现大量警告信息：

[WARNING] Failed to download maven-metadata.xml from http://nexus.xxx.local/repository/idmp-maven-thirdparty/
[WARNING] Failed to download xxx.pom from http://nexus.xxx.local/repository/idmp-maven-thirdparty/
[WARNING] Failed to download xxx.jar from http://nexus.xxx.local/repository/idmp-maven-thirdparty/

诡异之处：

• 通过浏览器直接访问仓库 URL，能够正常看到 JAR 文件
• 相同的 settings.xml 配置在 Maven 3.6.3 上工作正常
• 网络连通性测试全部通过

排查过程

第一阶段：网络问题排查

首先怀疑是网络或 DNS 问题：

# 测试网络连通性
ping nexus.xxx.local
# 结果：正常# 测试端口访问
telnet nexus.xxx.local 80
# 结果：正常# 直接访问仓库
curl -I http://nexus.xxx.local/repository/idmp-maven-thirdparty/
# 结果：返回 200 OK

网络层面一切正常，排除基础连接问题。

第二阶段：Maven 配置检查

检查 settings.xml 配置，确认仓库配置正确：

<repository><id>idmp-maven-thirdparty</id><name>Internal Thirdparty Repository</name><url>http://nexus.xxx.local/repository/idmp-maven-thirdparty/</url><releases><enabled>true</enabled></releases><snapshots><enabled>true</enabled></snapshots>
</repository>

配置看起来没有问题，在 Maven 3.6.3 上能够正常工作。

第三阶段：深入分析 Maven 行为

启用 Maven 调试模式：

mvn clean install -X

在详细的调试日志中，发现关键信息：

Blocked mirror for repositories: [idmp-maven-thirdparty (http://nexus.xxx.local/repository/idmp-maven-thirdparty/, default, releases+snapshots)]

这才意识到问题所在：Maven 3.8.1+ 版本默认阻止所有 HTTP 仓库访问。

根本原因

经过查阅 Maven 官方文档，发现从 Maven 3.8.1 开始引入了一项重要的安全改进：

Maven 3.8.1 默认阻止所有 HTTP 仓库访问，强制要求使用 HTTPS，以防止中间人攻击。

这是通过在 settings.xml 中默认配置的 maven-default-http-blocker 镜像实现的：

<mirror><id>maven-default-http-blocker</id><mirrorOf>external:http:*</mirrorOf><name>Pseudo repository to mirror external repositories initially using HTTP.</name><url>http://0.0.0.0/</url><blocked>true</blocked>
</mirror>

解决方案尝试

方案一：修改 settings.xml 绕过阻止

尝试在 settings.xml 中覆盖默认的 HTTP 阻止策略：

<mirrors><mirror><id>maven-default-http-blocker</id><mirrorOf>dummy</mirrorOf><name>Disable HTTP blocker</name><url>http://0.0.0.0/</url></mirror>
</mirrors>

结果：部分解决，但仍有其他限制。

方案二：使用 Maven 3.6.3（最终方案）

由于公司内部仓库暂时无法升级到 HTTPS，最终选择回退到 Maven 3.6.3：

# 下载 Maven 3.6.3
wget https://archive.apache.org/dist/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.zip# 安装并配置
unzip apache-maven-3.6.3-bin.zip
sudo mv apache-maven-3.6.3 /usr/local/# 更新环境变量
export MAVEN_HOME=/usr/local/apache-maven-3.6.3
export PATH=$MAVEN_HOME/bin:$PATH

验证：

mvn -version
mvn clean install  # 成功！

经验总结

1. 版本兼容性检查很重要：在升级构建工具前，务必检查新版本的重大变更
2. 安全与便利的权衡：Maven 3.8.1+ 的安全改进是合理的，但对于尚未升级 HTTPS 的内部仓库会造成兼容性问题
3. 调试信息是关键：mvn -X 提供的详细日志是排查复杂问题的利器

长期解决方案

• 推动基础设施团队将内部 Nexus 仓库升级为 HTTPS
• 在团队文档中记录 Maven 版本与仓库协议的兼容性要求
• 考虑搭建内部镜像仓库，统一依赖管理策略

临时应对措施

在团队内部：

• 统一使用 Maven 3.6.3 版本
• 在项目 README 中明确 Maven 版本要求
• 为新同事准备包含正确 Maven 版本的工具包

这次经历再次证明了：有时候不是你的配置有问题，而是工具在保护你免受潜在的安全威胁。在享受便利的同时，我们也要理解并适应这些安全改进。