PAYATHON 2026

Immutant2 server 日志出现可疑的 Undertow 错误

支付小周

结论

这通常与应用是否集成 Alipay 无关。从日志看，某个客户端把 Immutant2/Undertow 的 HTTP 端口当作代理服务器，并发送了代理隧道请求：

CONNECT www.alipay.com:443 HTTP/1.1

Undertow 收到了请求，但当前服务只是普通的 Servlet Web 应用，没有配置 HTTP 正向代理，也没有能够处理 CONNECT 方法及该请求目标的 Servlet 路由。因此，Servlet 路径匹配失败并抛出：

UT000068: Servlet path match failed

如果服务端口暴露在公网，常见原因是自动化扫描器在寻找可滥用的开放代理。如果端口只对内网开放，则要检查客户端、系统代理、浏览器扩展或网络设备，确认是否误将该地址设成了代理服务器。

为什么请求中会出现 Alipay

HTTP CONNECT 方法主要用于让代理服务器建立 TCP 隧道，通常用来转发 HTTPS 流量。客户端会直接把目标主机和端口写入请求目标：

CONNECT www.alipay.com:443 HTTP/1.1
Host: www.alipay.com:443

这不代表 Immutant 应用主动连接了 Alipay，也不能说明应用代码引用了支付接口。www.alipay.com:443 只是请求方提供的目标地址，出现在发往服务器的原始 HTTP 请求中。

扫描器可能用这个域名测试代理能否访问一个稳定的 HTTPS 网站，也可能是某个代理检测工具预设了该测试目标。仅凭这一条日志，无法判断请求方的身份或动机。

为什么会触发 UT000068

Servlet 应用通常接收这样的请求：

GET /status HTTP/1.1
Host: example.com

其中的 /status 可以按照 Servlet 映射规则匹配到相应的处理器。

代理形式的 CONNECT 请求则使用 host:port 作为请求目标：

www.alipay.com:443

旧版 Undertow 的 Servlet 路径匹配流程可能无法将这种请求目标作为有效的 Servlet 路径处理，因而抛出 IllegalArgumentException。这条异常更像是一个不适用的请求进入了 Servlet 处理链，不一定说明应用本身发生了业务故障。

建议的排查步骤

1. 确认端口是否暴露在公网

检查防火墙、安全组、路由器端口转发以及容器端口映射。如果测试服务不需要公网访问，应只监听回环地址或内网地址，例如：

(run app {:host "127.0.0.1"
          :port 8080})

具体配置取决于 Immutant/WunderBoss 的启动方式。没有确认配置语义前，不要直接照搬这段代码。

2. 查询请求来源

查看 Undertow 访问日志、反向代理日志或防火墙日志，重点记录以下信息：

  • 源 IP 和源端口
  • 请求时间
  • HTTP 方法
  • 请求目标
  • Host、User-Agent 等请求头
  • 同一来源是否还访问了其他代理测试地址

当前的异常堆栈没有源 IP。仅凭这段日志，无法判断请求来自公网、局域网还是本机进程。

3. 检查代理配置

如果源地址属于自己的设备，应检查：

  • 操作系统的 HTTP/HTTPS 代理设置
  • 浏览器代理设置和扩展
  • Java 启动参数，如 http.proxyHost、https.proxyHost
  • HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 环境变量
  • 测试工具、抓包软件、VPN 或网关设备
  • 容器和 CI 环境中的代理变量

尤其要确认是否误将应用地址配置成：

http://server-address:application-port

4. 在入口层拒绝 CONNECT

普通 Web 应用通常不需要接受 CONNECT。如果服务前面有 Nginx，可以明确限制该请求方法：

location / {
    if ($request_method = CONNECT) {
        return 405;
    }

    proxy_pass http://127.0.0.1:8080;
}

在 Nginx 中使用 if 需要谨慎，这里只是展示一种简单的入口拦截方式。实际配置也可以使用 limit_except、网关策略、WAF 或防火墙。

应用层同样可以拒绝不需要的方法，例如添加 Ring 中间件：

(defn reject-connect [handler]
  (fn [request]
    (if (= :connect (:request-method request))
      {:status 405
       :headers {"Content-Type" "text/plain; charset=utf-8"
                 "Allow" "GET, HEAD, POST, PUT, DELETE, OPTIONS"}
       :body "Method Not Allowed"}
      (handler request))))

但这段异常可能在请求到达 Ring 处理器之前就已经发生。此时应用中间件无法拦截，需要在反向代理、防火墙或 Undertow 配置层处理。

5. 评估升级 Undertow/Immutant

如果使用的是较旧版本的 Immutant2、Undertow 或 WildFly 组件，可以核对相应版本的变更记录，并在测试环境中评估升级。升级可能改善异常请求的解析和错误处理，但无法代替访问控制，也不能阻止公网扫描。

在确认完整版本、依赖树和部署方式之前，不能断定某个特定版本一定修复了这一现象。

安全方面需要注意什么

只有这一条日志，还不足以证明服务器已被入侵。它首先说明有人或某个程序向服务端口发送了代理格式的请求。

仍需确认服务器没有被配置成可用的开放代理。可以从受控客户端发送测试请求：

curl -v -x http://server-address:port https://example.com/

正常的普通 Web 应用应拒绝该请求，或者无法建立隧道。不要对不属于自己的服务器进行此类测试。

如果请求只出现一两次，来源是陌生的公网 IP，而且代理测试失败，通常可以视为常见的互联网扫描。如果同一来源持续发送请求、请求量明显增加，或者服务器确实成功转发了流量，应立即限制端口访问，检查代理相关配置，并审查网络连接和系统日志。

备注：内容仅供参考。