Pre-check
Search before asking
Apache Dubbo Component
Java SDK (apache/dubbo)
Descriptions
Body:
Hello maintainers,
We are currently using Dubbo 3.3.6 with the tri (Triple) protocol. While reviewing the source code, I noticed that org.apache.dubbo.remoting.transport.netty4.NettyConnectionClient still contains the following TODO:
// set null but do not close this client, it will be reconnecting in the future
ch.closeFuture().addListener(channelFuture -> clearNettyChannel());
// TODO support Socks5
From our current testing, it seems that tri protocol does not yet support SOCKS5 proxying on the client side. JVM-level proxy settings such as:
-DsocksProxyHost=...
-DsocksProxyPort=...
do not appear to work for tri connections, which is understandable since the client is based on Netty rather than plain JDK sockets.
We have a real use case for this feature, such as:
- local development environments accessing remote Dubbo services through a SOCKS5 proxy
- cross-network or restricted-network scenarios where direct connectivity is not available
Could you please clarify:
- Is SOCKS5 support for tri protocol already on the roadmap?
- If yes, is there any planned version or milestone for it?
- If not, what would be the recommended extension point or workaround for now?
For example, is it expected to support something like Netty's Socks5ProxyHandler in the client pipeline in the future?
Environment:
- Dubbo version: 3.3.6
- Protocol: tri / Triple
- Transport: Netty
Thanks in advance.
Related issues
No response
Are you willing to submit a pull request to fix on your own?
Code of Conduct
Pre-check
Search before asking
Apache Dubbo Component
Java SDK (apache/dubbo)
Descriptions
Body:
Hello maintainers,
We are currently using Dubbo 3.3.6 with the tri (Triple) protocol. While reviewing the source code, I noticed that
org.apache.dubbo.remoting.transport.netty4.NettyConnectionClientstill contains the following TODO:From our current testing, it seems that tri protocol does not yet support SOCKS5 proxying on the client side. JVM-level proxy settings such as:
do not appear to work for tri connections, which is understandable since the client is based on Netty rather than plain JDK sockets.
We have a real use case for this feature, such as:
Could you please clarify:
For example, is it expected to support something like Netty's
Socks5ProxyHandlerin the client pipeline in the future?Environment:
Thanks in advance.
Related issues
No response
Are you willing to submit a pull request to fix on your own?
Code of Conduct