HttpsURLConnection在Eclipse运行正常 导出可运行JAR命令行返回503错误

两类运行环境下代码逻辑完全一致，仅独立运行Runnable JAR时触发目标服务器返回503，说明并非业务代码逻辑错误，而是运行时环境差异导致请求特征变化，触发了服务器侧反爬/WAF拦截规则。最常见的触发原因包括：

• 类加载偏差导致TLS安全栈实现不一致
  Eclipse运行程序时，默认使用本地JDK原生JSSE安全栈完成HTTPS握手，无第三方安全提供者插队；导出Runnable JAR时若选择“将依赖解压合并进JAR”的打包选项，很容易被第三方网络库、加密库携带的META-INF/services安全配置覆盖原生规则，导致JVM优先加载第三方URLConnection实现。这类实现的TLS握手加密套件、协议版本、握手指纹和原生JSSE存在明显差异，会被WAF识别为非浏览器特征的爬虫流量，直接返回503。
• 运行时网络环境配置不统一
  Eclipse启动程序时，JVM会自动继承系统代理、DNS解析规则、网络类系统属性（如https.protocols、http.agent）；而通过java -jar独立启动JAR时，不会自动加载Eclipse附带的这些环境参数。最常见的场景是IDE运行时默认走办公网代理出口IP，该IP段被目标服务器信任；JAR独立运行时未配置代理，使用本地直连出口，该IP段被WAF拦截时就会返回503。
• 隐式请求头特征差异
  虽然代码中明确设置了User-Agent，但不同JSSE实现的HttpsURLConnection会自动补充不同的隐式请求头（如Accept-Encoding、Connection、Upgrade-Insecure-Requests等），如果第三方实现补充的头信息不符合常规浏览器配置，也会触发拦截。

按优先级逐步验证：

• 对比两个场景下的运行时核心配置
  在代码中分别打印以下信息，分别在IDE、独立JAR两个场景下运行对比：
  • 打印JVM加载的所有安全提供者列表：遍历Security.getProviders()输出每个提供者的名称
  • 打印HttpsURLConnection的实际实现类：输出con.getClass().getName()
  • 打印当前生效的代理配置：输出System.getProperty("http.proxyHost")、System.getProperty("https.proxyHost")
    如果发现输出存在差异，首先调整Runnable JAR的打包配置，选择“将依赖打包为内嵌JAR”模式，不要将依赖解压到JAR根目录，避免第三方配置覆盖JDK原生安全规则。
• 补全标准浏览器请求头
  在现有连接配置逻辑中，补充常规浏览器访问的标准请求头，消除不同实现的隐式头差异，示例配置如下：
  • con.setRequestProperty("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8")
  • con.setRequestProperty("Accept-Language", "zh-CN,zh;q=0.9,en;q=0.8")
  • con.setRequestProperty("Accept-Encoding", "gzip, deflate")
    同时在连接初始化前强制指定通用TLS协议版本，避免不同JVM的默认版本偏差：
    System.setProperty("https.protocols", "TLSv1.2,TLSv1.3")
• 对齐运行时网络参数
  打开Eclipse的运行配置页，复制VM参数中和网络相关的配置（如代理地址、端口、TLS版本参数），在独立启动JAR时通过-D参数手动传入，保证两个场景下的网络出口、协议配置完全一致。
• 修正现有代码的异常处理逻辑
  当前try块仅捕获MalformedURLException，未覆盖连接阶段的IO异常，一旦出现URL格式错误、流初始化失败的情况，会出现空指针或异常向上抛出的问题；建议将异常捕获范围调整为捕获IOException，或者在捕获URL异常后重新抛出，避免无效的流读取逻辑。

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