[Bug] SOCKS proxy CIDR matching throws NumberFormatException for hostname or IPv6 addresses, so the client cannot connect

Đang mở
  • Có gì không ổn?
#11,483 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@weidong-qi đang làm issue này rồi.

Từ ngày 22/10/2026.

  • #11484 của @weidong-qi — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
java
Lĩnh vực
backend

Hướng nghiên cứu

Start in NettyRemotingClient#getProxy, then trace how RemotingHelper#ipInCIDR parses hosts against configured CIDR keys. Check the existing tests for SOCKS proxy selection and add coverage for hostname and IPv6 targets with an IPv4 CIDR, plus the 0.0.0.0/0 catch-all. Done means nonmatching targets do not throw and connection setup can proceed; linked pull request #11484 is already open.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Before Creating the Bug Report
  • I found a bug, not just asking a question, which should be created in GitHub Discussions.
  • I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.
  • I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.
Runtime platform environment

Any (reproduced on macOS)

RocketMQ version

develop, git commit id: 57c2dc04f78cc7e73e6b8c9436ee0fff0d0f46c3

JDK Version

JDK 17

Describe the Bug

NettyRemotingClient#getProxy picks a SOCKS proxy by matching the target host against each CIDR key of socksProxyConfig. For every key other than the literal 0.0.0.0/0 it calls RemotingHelper#ipInCIDR(host, cidr), which parses the host with ipToInt and only accepts dotted IPv4 literals.

When the target address uses a hostname (e.g. namesrv.example.com:9876, common with Kubernetes service names) or an IPv6 literal, ipToInt throws NumberFormatException. The exception escapes getProxy → fetchBootstrap → doConnect, so the client cannot connect to that address at all, even though it should just not match that CIDR.

Steps to Reproduce
NettyClientConfig config = new NettyClientConfig();
config.setSocksProxyConfig("{\"10.0.0.0/8\":{\"addr\":\"127.0.0.1:1080\"}}");
NettyRemotingClient client = new NettyRemotingClient(config);
// any invoke against "namesrv.example.com:9876" reaches getProxy(...)

Calling getProxy("namesrv.example.com:9876") (e.g. via reflection) throws:

java.lang.NumberFormatException: For input string: "namesrv"
	at org.apache.rocketmq.remoting.common.RemotingHelper.ipToInt(RemotingHelper.java)
	at org.apache.rocketmq.remoting.common.RemotingHelper.ipInCIDR(RemotingHelper.java)
	at org.apache.rocketmq.remoting.netty.NettyRemotingClient.getProxy(NettyRemotingClient.java)
What Did You Expect to See?

A hostname or IPv6 host that cannot be compared against an IPv4 CIDR does not match that entry (no proxy, direct connection), and can still match the 0.0.0.0/0 catch-all entry.

What Did You See Instead?

NumberFormatException is thrown and the connection attempt fails.

Additional Context

This is separate from #11068, which fixes the /0 mask computation inside ipInCIDR. The fix proposed here only touches NettyRemotingClient#getProxy, so the two changes do not overlap.

Ngôn ngữ chính
Java
Star
22.7k
Fork
12k
Merge trung bình
3 ngày 18 giờ
Pull request đã merge (30 ngày)
17

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/rocketmq

Tất cả issue của apache/rocketmq

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.