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

Open
  • Is something wrong?
#11,483 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@weidong-qi is already working on this.

Since Oct 22, 2026.

  • #11484 by @weidong-qi — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
25/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
java
Domain
backend

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Java
Stars
22.7k
Forks
12k
Avg merge
3d 18h
Merged PRs (30d)
17

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/rocketmq

All issues in apache/rocketmq

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.