Maven/Tycho构建时VPN环境下无法访问P2更新站点问题

按以下顺序逐步排查，覆盖90%以上同类场景问题：

• 先排除浏览器测试的误导性：浏览器默认会自动加载系统代理、自动跟随跳转、带完整的浏览器特征请求头，和Java进程/maven命令行的网络行为完全不一致。连VPN后先在终端执行curl -v https://<some-p2-repo>/content.xml，观察返回结果：
  • 如果curl直接报Connection reset，说明问题在网络层/代理层，和Tycho本身无关
  • 如果curl返回301/302跳转、403/406错误，说明是反向代理/WAF拦截了非浏览器特征的请求
  • 如果curl能正常返回二进制的content.jar内容，说明链路本身通，问题出在JVM或Tycho配置
• 检查JVM代理配置：公司VPN一般会下发全局系统代理，但Java进程默认不会主动读取系统代理配置，会直连目标地址，很容易被VPN网关拦截重置。构建时先加参数强制JVM使用系统代理，同时开HTTP层debug日志看实际请求链路：

export MAVEN_OPTS="-Djava.net.useSystemProxies=true -Dorg.slf4j.simpleLogger.log.org.apache.http=debug"
mvn clean verify

从debug日志里可以直接看到Java进程实际连接的IP/端口、是否走了代理、SSL握手是否正常、在哪一步被断开。如果之前在maven的settings.xml里配过非VPN环境的代理，记得先注释掉，避免连VPN后旧代理地址不可达导致报错。

• 强制Tycho读取压缩格式的p2元数据：部分p2仓库服务端/WAF会拦截对content.xml的明文请求，只允许请求压缩后的content.jar。可以在你的target文件对应的仓库配置里加属性，跳过xml文件的拉取逻辑：

<repository location="https://<some-p2-repo>">
  <properties>
    <property name="p2.compressed" value="true"/>
    <property name="p2.metadata.reference.optional" value="true"/>
  </properties>
</repository>

修改后先删除本地maven仓库下该p2仓库的缓存目录（路径一般为~/.m2/repository/p2/osgi/cache/下对应仓库地址的子目录），再重新构建。

• 排查VPN链路MTU问题：这是VPN场景下的高频隐性坑，VPN封装数据包会额外加包头，会导致链路MTU低于普通公网的1500，如果VPN网关没开MSS钳制，Java进程发出的较大请求包会被直接丢弃重置，而浏览器因为用了分块传输、请求包更小，往往能正常访问。可以临时把VPN虚拟网卡的MTU改成1380再测试：
  • Windows：执行netsh interface ipv4 set subinterface "你的VPN网卡名称" mtu=1380 store=persistent
  • Linux/macOS：执行sudo ifconfig <VPN网卡名> mtu 1380
• 排查HTTPS证书信任问题：如果公司VPN开启了HTTPS流量解密，会用公司自签根证书替换站点证书，浏览器一般会自动同步公司域的根证书所以访问正常，但JVM自带的cacerts信任库默认没有公司根证书，SSL握手阶段就会被断开。如果debug日志看到SSL握手阶段报错，直接把公司根证书导入$JAVA_HOME/lib/security/cacerts即可。

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