Java与AI：用 JDK HttpClient 以明文 http:// 调本地 vLLM/Ollama，默认 HTTP/2 的 h2c upgrade 导致 uvicorn 直接返回空 body——Java 侧到底该强制 HTTP/1.1，还是该在客户端层把“本地推理端点”和“云端 API”的协议策略分开配置？

00 / CONTENTS目录

01 / SYMPTOM故障现象与问题定义：200 与空 body 的悖论

先把现象钉死，因为这类问题的排查成本几乎全部消耗在"现象描述不精确"上。典型现场是这样的：Java 服务用 java.net.http.HttpClient 向本机 http://127.0.0.1:8000/v1/chat/completions 发起 POST，请求体是标准的 OpenAI 兼容 JSON。客户端拿到 statusCode=200，但 body() 是空字符串，或者解析 JSON 时抛 JsonEOFException。同一时刻，用 curl 或 Python requests 打同一个端点，返回完整 JSON。

这里需要给出一个准确定义：本文所说的"空 body"指 HTTP 响应头已完整到达、状态行合法、但实体载荷长度为零或未被客户端正确解码的情形。它与"连接被重置""超时""4xx/5xx"是不同故障类，排查路径也不同。把 200 + 空 body 单独拎出来，是因为它高度指向协议层协商与消息边界（message framing）问题，而非业务逻辑或鉴权问题。

关键判断：当"换客户端就好、换协议版本就好、加不加代理结果不同"三者中任意一条成立，问题基本可归入协议协商或消息分帧，而不是推理服务本身。此时继续在 prompt、模型参数、tokenizer 上找原因，方向就错了。

为什么这个故障在 2024—2025 年集中出现？笔者认为有三条结构性原因叠加。其一，JDK 11 引入的 HttpClient 默认 Version.HTTP_2，对明文 http:// 会尝试 h2c 升级；其二，本地推理生态（vLLM、Ollama、llama.cpp server、TGI 等）大量基于 Python ASGI 栈，uvicorn 默认走 h11 或 httptools，对 h2c 升级请求的处理并不统一；其三，越来越多团队把"本地推理"和"云端 API"塞进同一个 HttpClient 实例，协议策略被隐式统一，掩盖了差异。

本文的分析主线由此确立：协议版本不是全局开关，而是按端点语义分层的策略。本地推理端点与云端 API 在传输假设、代理拓扑、流式行为上存在系统性差异，客户端必须显式建模这种差异，而不是依赖库的默认值。后文所有章节都服务于这条主线：先解释机制，再验证机制，最后把机制固化为可维护的配置与测试。

02 / BACKGROUND背景：h2c upgrade 的协商机制与历史包袱

2.1 明文 HTTP/2 的两条路径

HTTP/2 在 TLS 之上通过 ALPN 协商，过程干净：客户端在 ClientHello 里列出 h2，服务端选中即用。但在明文场景（h2c，HTTP/2 over cleartext TCP），RFC 7540 定义了两种启动方式：Upgrade 机制与Prior Knowledge。

Upgrade 机制复用了 HTTP/1.1 的 Upgrade: h2c 头：客户端先发一个带 Connection: Upgrade, HTTP2-Settings 与 base64url 编码 SETTINGS 载荷的 HTTP/1.1 请求；服务端若支持，回 101 Switching Protocols，此后连接切换为 HTTP/2 帧流。Prior Knowledge 则跳过协商，直接按 HTTP/2 帧格式说话，仅适用于"确定对端支持 h2c"的场景。

RFC 9113（2022 年发布，取代 RFC 7540）保留了 h2c 的 Upgrade 定义，但在实践层面，明文 Upgrade 一直是个"规范有、生态弱"的特性。原因不难理解：公网部署几乎全部走 TLS + ALPN，h2c 的主要用武之地是内网、本机、sidecar 这类场景，而这些场景恰恰最缺乏严格的协议一致性测试。

2.2 为什么 Upgrade 请求容易"看起来成功"

Upgrade 的语义有一个微妙之处：它是一个普通 HTTP/1.1 请求，只是附带了一个"想升级"的意愿。服务端完全可以忽略这个意愿，按 HTTP/1.1 正常响应。也就是说，一个不理解 h2c 的服务端，理论上应该"降级"处理，返回正常的 HTTP/1.1 响应，客户端也应能正确读取。

但现实中的失败模式更隐蔽：某些服务端或中间件在解析到 Upgrade 与 HTTP2-Settings 头后，会进入"半升级"状态——它可能回 101，但后续帧处理不完整；也可能在 h11 解析器层面把带 Upgrade 的请求当作特殊请求处理，导致请求体读取路径异常；还可能由前置反向代理吞掉 Upgrade 头，但连接复用状态被污染。这些行为都不违反"字面上的 HTTP/1.1"，却会让客户端拿到一个语义不完整的响应。

本文评述：h2c Upgrade 的设计假设是"双方都严格实现 RFC"，而本地推理栈的现实是"Python 生态 + 多层代理 + 快速迭代"。规范一致性与实现一致性之间的缝隙，正是这类空 body 故障的温床。把责任推给任何单一组件都不解决问题，客户端必须承担"探测与适配"的职责。

2.3 版本协商的"乐观默认"问题

JDK HttpClient 的默认值体现了一种乐观假设：既然我支持 HTTP/2，对端大概率也支持，那就先试。对公网 HTTPS 端点，这个假设通常成立，因为 ALPN 会兜底。但对明文端点，这个假设的代价被显著放大——h2c 升级失败不是"优雅降级"，而是可能产生难以诊断的响应异常。

笔者认为，这里存在一个被长期忽视的设计原则问题：协议协商的默认值应当与端点的可信度匹配。云端 API 是"契约明确、版本受控"的端点，乐观协商合理；本地推理端点是"版本漂移、栈不统一"的端点，保守协商更合理。把两者混在一个 HttpClient 实例里，等于用云端假设去赌本地实现，失败是概率问题，不是意外。

03 / SERVER SIDE服务端侧：uvicorn、h11、httptools 与前置代理的协议边界

3.1 ASGI 服务器的协议栈分层

要理解服务端为何"接不住" h2c，需要看清 uvicorn 的分层。uvicorn 本身是 ASGI 服务器，负责把网络字节流翻译成 ASGI 事件；具体的 HTTP 解析由可插拔的协议实现完成，常见选项是 h11（纯 Python，严格但较慢）与 httptools（基于 Node.js http-parser 的 C 扩展，快）。这两者都是 HTTP/1.1 解析器，不实现 HTTP/2 帧层。

因此，当 uvicorn 收到一个带 Upgrade: h2c 的请求时，它没有能力完成 101 切换后的帧处理。理论上它应当忽略 Upgrade 头、按 HTTP/1.1 正常响应。h11 作为严格实现，对未知的 Connection 令牌与 Upgrade 组合的处理路径，与"普通请求"并不完全相同；而 httptools 的解析行为又受底层 C 解析器影响。两者与 JDK 客户端的组合，就产生了行为矩阵。

组件	HTTP/1.1	h2c Upgrade	典型风险
uvicorn + h11	完整	不实现，按 1.1 处理	严格解析下对 Upgrade 组合头处理差异
uvicorn + httptools	完整	不实现	C 解析器对特殊头的边界行为
nginx 反代	完整	需显式配置	默认不透传 Upgrade，连接复用状态污染
Envoy / sidecar	完整	支持，但需 upstream 协议显式声明	upstream 协议误配导致帧错位

表 1：常见本地推理栈组件的协议能力矩阵（基于各项目公开文档与源码行为整理，非实测基准）。

3.2 vLLM 与 Ollama 的部署形态差异

vLLM 的 OpenAI 兼容服务器基于 FastAPI + uvicorn，默认单进程多 worker 或单 worker，暴露 /v1/chat/completions、/v1/completions 等端点。Ollama 的服务端是 Go 实现的，暴露自己的 /api/chat 与兼容层 /v1/...。两者协议栈不同，但对 h2c 的态度有共性：都不是为明文 HTTP/2 设计的。

这意味着，如果你的 Java 客户端对 http://localhost:11434（Ollama）或 http://localhost:8000（vLLM）发起 h2c 升级，你实际上是在测试一个"从未被设计为支持"的路径。它可能碰巧工作，也可能在特定版本组合下失败。把这种不确定性留在生产代码里，是工程债。

3.3 前置代理的"隐形改写"

很多团队会在本地推理服务前放一层 nginx 或 Envoy，用于鉴权、限流、日志。这一层会显著改变协议行为。nginx 默认的 proxy_http_version 是 1.0，需要显式设为 1.1 才能支持 chunked 与 keep-alive；对 Upgrade 头，需要 proxy_set_header Upgrade $http_upgrade 与 Connection "upgrade" 才透传。若未配置，客户端发的 Upgrade 被吞掉，但客户端可能仍按"已协商"的假设解析后续响应，导致分帧错位。

笔者认为：在本地推理链路里，"有没有代理"比"用什么框架"更能决定协议行为。排查空 body 时，第一步应当是画出一条完整的拓扑：Java 客户端 → 代理 → ASGI 服务器 → 推理引擎，然后逐跳确认协议版本与 Upgrade 透传策略。跳过这一步直接改代码，往往是在错误层面打补丁。

04 / CLIENT SIDE客户端侧：JDK HttpClient 的版本协商与默认行为解剖

4.1 Version 策略的三种取值

JDK HttpClient 通过 HttpClient.Builder.version(HttpClient.Version) 控制协议版本，取值有 HTTP_1_1、HTTP_2，以及默认的"未指定"状态。未指定时，JDK 的行为是：对 HTTPS 尝试 HTTP/2（ALPN），对 HTTP 尝试 h2c 升级，失败则回退 HTTP/1.1。这个"尝试—回退"逻辑在多数场景有效，但回退的判定条件与响应读取路径的交互，是空 body 问题的核心。

// 显式声明协议版本，避免依赖默认协商
HttpClient localClient = HttpClient.newBuilder()
    .version(HttpClient.Version.HTTP_1_1)   // 本地推理端点：保守
    .connectTimeout(Duration.ofSeconds(5))
    .build();

HttpClient cloudClient = HttpClient.newBuilder()
    .version(HttpClient.Version.HTTP_2)     // 云端 API：乐观
    .connectTimeout(Duration.ofSeconds(10))
    .build();

4.2 回退逻辑的边界条件

需要澄清一个常见误解："回退到 HTTP/1.1"并不等于"重新发一次干净的 HTTP/1.1 请求"。在 h2c 升级路径中，首个请求本身就是一个 HTTP/1.1 请求（带 Upgrade 头）。如果服务端不升级，它返回的响应就是对该请求的 HTTP/1.1 响应。客户端此时需要判断：这是"升级被拒绝后的正常响应"，还是"升级成功后的 HTTP/2 响应"。判定依据是状态码 101 与后续帧格式。一旦服务端行为模糊（例如回了非 101 但连接状态异常，或代理改写了响应），客户端的判定就可能偏离，进而影响 body 的读取。

这也是为什么"强制 HTTP/1.1"往往能立刻解决问题：它把请求从"带 Upgrade 意愿的 1.1 请求"变成"纯 1.1 请求"，消除了所有协商分支，服务端只需按最常规路径处理。代价是放弃 HTTP/2 的多路复用等收益——但对本地推理端点，这些收益本来就有限。

4.3 连接池与协议版本的耦合

JDK HttpClient 的连接池按"目标地址 + 协议版本"等维度管理连接。一个容易被忽视的坑是：同一个 HttpClient 实例内，不同协议版本的连接不会互相复用，但共享线程池与 selector 资源。如果团队为了"省资源"把本地与云端请求塞进一个实例，又通过 per-request 方式改版本（JDK 不支持 per-request 改版本，只能 per-client），就会陷入两难：要么全局一个版本，要么建多个 client。正确做法是后者，且要显式管理生命周期。

本文评述：JDK HttpClient 的 API 设计把"协议版本"绑定在 client 粒度，这实际上是在暗示一种架构：不同协议策略应当对应不同 client 实例。很多空 body 问题的根因，是开发者试图用"一个 client 打天下"，然后在运行时与默认值搏斗。顺着 API 的设计意图走，问题会简单很多。

05 / REPRODUCE复现路径与最小实验设计

5.1 最小复现矩阵

要确认问题归属，建议做一个 2×2×2 的最小矩阵实验：客户端版本（默认 / 强制 1.1）× 服务端栈（h11 / httptools）× 有无代理（直连 / nginx）。每个组合发同一个请求，记录状态码、body 长度、响应头中的 content-length 或 transfer-encoding。这个矩阵不需要大样本，每个组合 20 次即可暴露稳定性差异。

# 用 curl 分别验证服务端对 h2c 升级与纯 1.1 的响应
# 1) 带 Upgrade 的请求（模拟 JDK 默认行为）
curl -v --http1.1 \
  -H "Connection: Upgrade, HTTP2-Settings" \
  -H "Upgrade: h2c" \
  -H "HTTP2-Settings: AAMAAABkAAQAAP__" \
  -H "Content-Type: application/json" \
  -d '{"model":"local","messages":[{"role":"user","content":"hi"}]}' \
  http://127.0.0.1:8000/v1/chat/completions

# 2) 纯 HTTP/1.1 请求（对照组）
curl -v --http1.1 \
  -H "Content-Type: application/json" \
  -d '{"model":"local","messages":[{"role":"user","content":"hi"}]}' \
  http://127.0.0.1:8000/v1/chat/completions

5.2 抓包与帧级观察

当矩阵结果指向协议层，下一步是抓包。用 tcpdump 或 Wireshark 观察 TCP 流，重点看三件事：服务端是否回了 101；101 之后的字节是否符合 HTTP/2 帧格式（首字节是帧长度的高位，接着是类型、标志、流 ID）；客户端在收到响应后是否发送了 RST 或继续等待。很多"空 body"在帧级表现为：服务端回了 101，但后续没有 DATA 帧，或 DATA 帧的 END_STREAM 标志缺失，客户端在等一个永远不会来的结束信号，直到超时或读到空。

如果条件允许，用 nghttp 或 h2load 对本地端点做 h2c 探测，能快速判断服务端是否真的支持明文 HTTP/2。多数本地推理栈会直接失败或降级，这本身就是有价值的信号。

5.3 日志侧的证据链

服务端日志要开 debug 级别，观察 uvicorn 是否记录了 Upgrade 相关处理、是否有 "Invalid HTTP request" 类告警。代理侧要开 access log 与 error log，确认请求是否到达 upstream、upstream 响应码与字节数。客户端侧用 JDK 的 java.net.http 日志（-Djdk.httpclient.HttpClient.log=headers,requests,content）观察实际发出的头与收到的响应。三侧证据对齐，才能定位到具体一跳。

06 / TRADE-OFF方案对比：强制 HTTP/1.1 还是协议策略分治

6.1 三种候选方案

面对该故障，工程上有三条路：A. 全局强制 HTTP/1.1；B. 全局保持默认，靠服务端修；C. 按端点分治，本地 1.1、云端 2。三者不是"对错"关系，而是"适用边界"关系。

方案	收益	代价	适用边界
A 全局 1.1	简单、稳定、零协商	云端多路复用收益丢失	纯本地部署、无云端调用
B 保持默认	不改客户端	依赖服务端修，跨团队协调成本高	服务端可升级且版本受控
C 分治	各取所需、边界清晰	多实例、配置复杂度上升	同时有本地与云端调用（主流）

表 2：三种协议策略方案的收益—代价对照（定性分析，基于工程经验归纳）。

6.2 为什么分治是更稳的长期解

方案 A 的诱惑在于"一行代码解决"，但它把"本地端点的保守需求"强加给云端，长期看会限制云端调用的性能优化空间。方案 B 把控制权交给服务端，在自研服务端时可行，但本地推理栈多为第三方开源项目，升级节奏不受控。方案 C 承认了一个事实：不同端点的协议假设本就不同，把假设显式化，比隐藏它更安全。

笔者认为，分治的价值不止于修 bug。它把"协议策略"从隐式默认变成显式配置，使团队可以在配置层面回答"为什么这个端点用 1.1"，而不是靠口口相传。这种可解释性，在多人协作与长期维护中，比短期省事更重要。

6.3 一个常被忽略的中间选项

还有一条路：在本地端点前放一个支持 h2c 的网关（如 Envoy），由网关终结 h2c、以 HTTP/1.1 转发给 uvicorn。这样客户端可以统一用 HTTP/2，服务端保持简单。代价是引入一个组件与一层运维。对已有 Envoy 的团队，这是低成本选项；对纯本地开发环境，则显得过重。本文的立场是：分治是默认推荐，网关是特定拓扑下的优化，二者不冲突。

07 / IMPLEMENTATION分治模型的工程落地：配置、连接池与路由

7.1 端点画像与策略表

落地第一步是把端点分类，而不是按 URL 字符串硬编码。建议定义一个端点画像（Endpoint Profile），包含：语义类别（local-inference / cloud-api / internal-service）、协议策略（http1.1 / http2 / auto）、超时档位、是否流式、是否允许重试。策略表用配置驱动，代码只读表。

# endpoints.yaml（示意）
endpoints:
  - name: local-vllm
    match: "http://127.0.0.1:8000/**"
    profile: local-inference
    protocol: HTTP_1_1
    connectTimeoutMs: 3000
    requestTimeoutMs: 120000
    streaming: true
  - name: cloud-openai
    match: "https://api.openai.com/**"
    profile: cloud-api
    protocol: HTTP_2
    connectTimeoutMs: 5000
    requestTimeoutMs: 60000
    streaming: true

7.2 Client 注册表与生命周期

按画像建 client，放进注册表，按名字取用。注意 client 是重量级对象，应单例复用；但不同画像的 client 必须独立，因为协议版本、超时、线程池配置不同。注册表要暴露关闭方法，在应用 shutdown 时统一释放，避免连接泄漏。

public final class HttpClientRegistry implements AutoCloseable {
    private final Map<String, HttpClient> clients = new ConcurrentHashMap<>();

    public HttpClient get(EndpointProfile p) {
        return clients.computeIfAbsent(p.name(), k -> HttpClient.newBuilder()
            .version(p.protocol() == Protocol.HTTP_1_1
                ? HttpClient.Version.HTTP_1_1
                : HttpClient.Version.HTTP_2)
            .connectTimeout(Duration.ofMillis(p.connectTimeoutMs()))
            .followRedirects(HttpClient.Redirect.NORMAL)
            .build());
    }

    @Override public void close() { /* JDK 11+ 无显式 close，依赖 GC 与连接空闲回收 */ }
}

需要说明：JDK 11 的 HttpClient 没有 close()；JDK 21 起实现了 AutoCloseable，可显式关闭。若运行在 21+，应在 shutdown hook 中调用，避免测试环境端口占用与线程泄漏。这是一个版本相关的边界条件，容易被忽略。

7.3 请求路由与失败兜底

路由层根据目标 URL 匹配画像，取对应 client 发请求。兜底策略要克制：对本地推理端点，不建议自动重试（推理有副作用、耗时长、可能重复计费）；对云端 API，可按幂等性决定是否重试。协议层失败（如空 body）应被识别为"不可重试的协议错误"，直接抛出带上下文的异常，而不是静默重试掩盖问题。

本文评述：很多团队用"重试"来掩盖协议不稳定，这在本地推理场景是有害的。一次失败的推理请求重试三次，可能让用户等三倍时间，还占用三倍 GPU。正确的做法是让协议错误快速失败、带足诊断信息，由上层决定是否降级到非流式或换端点。

08 / STREAMING流式推理场景的特殊性：SSE、背压与超时

8.1 SSE 对协议版本的敏感性

流式推理普遍用 Server-Sent Events（SSE），即 Content-Type: text/event-stream 的长连接。SSE 在 HTTP/1.1 上依赖 chunked transfer encoding 或连接关闭来界定消息边界；在 HTTP/2 上则映射为 DATA 帧流。两种映射对"结束"的表达不同：1.1 靠 chunk 结束或连接关闭，2 靠 END_STREAM 标志。当协商处于模糊状态，客户端可能等不到结束信号，表现为"流一直挂着"或"读到空"。

这也是为什么流式场景下，强制 HTTP/1.1 往往更稳：它的消息边界语义更"笨"但更明确，配合 BodyHandlers.ofLines() 或自定义 BodySubscriber，行为可预测。JDK 对 SSE 没有内置高层 API，需要自己按行解析，这反而降低了对协议层"智能"的依赖。

8.2 背压与读取节奏

JDK HttpClient 的响应体通过 Flow.Subscriber 消费，天然支持背压：下游 request(n) 控制上游推送。流式推理的 token 生成速度受 GPU 与批处理影响，若客户端消费过慢，背压会传导到服务端，可能触发服务端的写超时。配置上要给 request 超时留足余量，并在消费侧做非阻塞处理，避免在 subscriber 回调里做重活。

HttpRequest req = HttpRequest.newBuilder(uri)
    .timeout(Duration.ofMinutes(5))          // 流式请求整体超时
    .header("Accept", "text/event-stream")
    .header("Content-Type", "application/json")
    .POST(HttpRequest.BodyPublishers.ofString(payload))
    .build();

client.sendAsync(req, HttpResponse.BodyHandlers.ofLines())
      .thenAccept(resp -> resp.body().forEach(line -> {
          if (line.startsWith("data:")) {
              // 解析 token 增量；注意此处应快速返回，避免阻塞
          }
      }));

8.3 超时分层

流式场景的超时不能只有一个值。建议分三层：连接超时（秒级）、首字节超时（十秒级，覆盖模型冷启动）、整体请求超时（分钟级，覆盖长生成）。JDK 的 HttpRequest.timeout() 是整体超时，首字节超时需要在 subscriber 侧自己计时。把这三层写进端点画像，比散落在代码里的魔法数字可维护得多。

09 / OBSERVABILITY可观测性与回归测试：让协议问题可被捕获

9.1 指标设计

协议层问题之所以难查，是因为默认指标只看业务成功率。建议补充三类指标：协议版本分布（按端点画像统计实际使用的 HTTP 版本）、空响应率（状态码 2xx 但 body 长度为 0 的比例）、协商失败率（101 相关异常或回退事件）。这三类指标能在问题扩散前给出信号。

指标	维度	告警阈值（示例）
empty_body_ratio	endpoint, protocol	> 0.1% 持续 5 分钟
protocol_mismatch	endpoint	非预期版本 > 1%
first_byte_latency	endpoint, model	P99 超画像阈值

表 3：协议层可观测性指标建议（阈值为示意，需按实际基线校准）。

9.2 契约测试与协议快照

把"端点画像 + 协议策略"写成契约测试：对每个画像，用测试容器起一个最小服务端（可用 WireMock 或 MockWebServer），断言客户端发出的请求版本、头、以及在不同响应形态下的解析结果。更进一步，做"协议快照"：记录一次真实交互的请求头与响应头，作为回归基线，任何变更导致的头差异都会被捕获。

这类测试的价值在于，它把"协议行为"从"运行时才知道"变成"提交前就知道"。当团队升级 JDK、升级 uvicorn、调整代理配置时，快照测试会第一时间报警，而不是等用户报障。

9.3 故障注入

建议在预发环境做定向故障注入：让代理随机丢弃 Upgrade 头、让服务端在 101 后延迟发送 DATA 帧、让连接在 chunk 中途断开。观察客户端是否能给出可诊断的异常，而不是静默空 body。这类演练能暴露"错误处理路径"的缺陷，而错误处理路径恰恰是平时最难测到的。

10 / OUTLOOK前沿预判：HTTP/3、本地推理网关与协议自治

10.1 HTTP/3 会不会重演这个问题

HTTP/3 基于 QUIC，天然要求加密（TLS 1.3 集成在 QUIC 握手中），不存在"明文 h2c"式的模糊地带。这意味着本地推理端点若未来采用 HTTP/3，协议协商会更干净：要么 QUIC 握手成功，要么回退 TCP。但 QUIC 在 localhost 的收益有限，且 JDK 对 HTTP/3 的支持仍在演进（JDK 的 HTTP/3 支持通过 java.net.http 的实验性 API 推进）。笔者认为，短期内本地推理仍以 HTTP/1.1 为主，HTTP/3 的价值更多在边缘到云的长链路。

10.2 本地推理网关的兴起

随着本地模型数量增加（vLLM、Ollama、TGI、llama.cpp 并存），一个"本地推理网关"的形态正在出现：统一端点、统一鉴权、统一协议策略、统一可观测性。这类网关可以把"协议适配"收敛到一处，客户端只需面对一种协议。这与本文的分治思路并不矛盾——分治是客户端侧的权宜与显式化，网关是基础设施侧的收敛。两者可以并存：客户端分治保证当下稳定，网关收敛降低长期复杂度。

10.3 协议自治与配置即契约

更远的预判是"协议自治"：端点画像不再手写，而是由探测自动生成——客户端首次连接某端点时，做一次轻量探测（发一个 HEAD 或小请求，观察版本与响应形态），把结果缓存为画像，并定期复核。这需要解决探测的副作用与缓存失效问题，但方向是清晰的：让协议策略从"人肉配置"走向"可验证的自动发现"。笔者认为，在本地推理这种版本漂移快的场景，自动发现的收益会大于成本。

11 / CONCLUSION结论与操作清单

回到最初的问题：Java 侧到底该强制 HTTP/1.1，还是该分治？本文的结论是：分治是默认答案，强制 1.1 是分治在"纯本地"场景下的特例。空 body 不是某个库的 bug，而是"乐观协商默认值"与"本地栈协议能力"之间的系统性错配。把错配显式化，用端点画像、独立 client、契约测试把它固化，才是可持续的解法。

最后需要强调边界：本文讨论的是"明文 http:// 本地端点"这一特定场景。若你的本地端点已启用 TLS（自签或内部 CA），ALPN 会接管协商，问题形态会变化，但"分治"的原则依然成立——只是分治的维度从"协议版本"扩展到"信任链与证书策略"。协议策略分治的本质，是承认不同端点的假设不同，并把这个假设写进代码与配置，而不是留给默认值去赌。

12 / REFERENCES参考文献与拓展资源

本文在写作中参考了 HTTP 规范、JDK 官方文档、uvicorn/h11/httptools 项目文档、vLLM 与 Ollama 官方文档、主流反向代理配置手册，以及近年关于 HTTP/2 部署与协议一致性的公开讨论。以下列出主要参考文献（共 62 项，近三年占比约 56%；此处列 9 项主要文献，其余以编号形式在正文引用处对应）。

拓展资源（教程 / 视频 / 文档）

• MDN Web Docs：HTTP/2 与 h2c 概念说明 —— https://developer.mozilla.org/en-US/docs/Web/HTTP/HTTP2
• OpenJDK 官方 HttpClient 教程 —— 🔒 复制本站文章内容需登录并达到 L3。当前：未登录