Skip to content

Feat: add option to disable UDP functionality#488

Open
SuzukiHonoka wants to merge 1 commit into
xjasonlyu:mainfrom
SuzukiHonoka:feat/add-option-disable-udp-fork
Open

Feat: add option to disable UDP functionality#488
SuzukiHonoka wants to merge 1 commit into
xjasonlyu:mainfrom
SuzukiHonoka:feat/add-option-disable-udp-fork

Conversation

@SuzukiHonoka

Copy link
Copy Markdown
Contributor

Some proxy server may not support udp, the udp processing logic may slow down performance, we can explicitly disable it before letting program to detect if the proxy server supports it.

@xjasonlyu xjasonlyu self-requested a review August 13, 2025 21:02
@xjasonlyu xjasonlyu added the enhancement New feature or request label Aug 13, 2025
@xjasonlyu

Copy link
Copy Markdown
Owner

Would it be possible to disable UDP at the stack level instead of at the tunnel/transportation level?

e.g.,

tun2socks/core/stack.go

Lines 48 to 52 in 61d8269

TransportProtocols: []stack.TransportProtocolFactory{
tcp.NewProtocol,
udp.NewProtocol,
icmp.NewProtocol4,
icmp.NewProtocol6,

or,

tun2socks/core/udp.go

Lines 14 to 38 in 61d8269

func withUDPHandler(handle func(adapter.UDPConn)) option.Option {
return func(s *stack.Stack) error {
udpForwarder := udp.NewForwarder(s, func(r *udp.ForwarderRequest) bool {
var (
wq waiter.Queue
id = r.ID()
)
ep, err := r.CreateEndpoint(&wq)
if err != nil {
glog.Debugf("forward udp request: %s:%d->%s:%d: %s",
id.RemoteAddress, id.RemotePort, id.LocalAddress, id.LocalPort, err)
return false
}
conn := &udpConn{
UDPConn: gonet.NewUDPConn(&wq, ep),
id: id,
}
handle(conn)
return true
})
s.SetTransportProtocolHandler(udp.ProtocolNumber, udpForwarder.HandlePacket)
return nil
}
}

IMO if we only disable UDP at the tunnel level, the gvisor stack would still have to handle the UDP "connection", which would lead to unnecessary overhead.

@SuzukiHonoka

Copy link
Copy Markdown
Contributor Author

Would it be possible to disable UDP at the stack level instead of at the tunnel/transportation level?

e.g.,

tun2socks/core/stack.go

Lines 48 to 52 in 61d8269

TransportProtocols: []stack.TransportProtocolFactory{
tcp.NewProtocol,
udp.NewProtocol,
icmp.NewProtocol4,
icmp.NewProtocol6,

or,

tun2socks/core/udp.go

Lines 14 to 38 in 61d8269

func withUDPHandler(handle func(adapter.UDPConn)) option.Option {
return func(s *stack.Stack) error {
udpForwarder := udp.NewForwarder(s, func(r *udp.ForwarderRequest) bool {
var (
wq waiter.Queue
id = r.ID()
)
ep, err := r.CreateEndpoint(&wq)
if err != nil {
glog.Debugf("forward udp request: %s:%d->%s:%d: %s",
id.RemoteAddress, id.RemotePort, id.LocalAddress, id.LocalPort, err)
return false
}
conn := &udpConn{
UDPConn: gonet.NewUDPConn(&wq, ep),
id: id,
}
handle(conn)
return true
})
s.SetTransportProtocolHandler(udp.ProtocolNumber, udpForwarder.HandlePacket)
return nil
}
}

IMO if we only disable UDP at the tunnel level, the gvisor stack would still have to handle the UDP "connection", which would lead to unnecessary overhead.

This looks reasonable, the main point is I want also log the udp request while blocking it, but if that causes overhead, we may simply remove the udp in TransportProtocols. I will re-check this in detail when I'm free.

@mimedo

mimedo commented Oct 18, 2025

Copy link
Copy Markdown

Is there a way to disable UDP? Somehow I can't connect to a proxy and support from the provider says I should try without UDP.

@xjasonlyu

Copy link
Copy Markdown
Owner

UDP should have nothing to do with connecting to a proxy (at least the TCP should work)

@mimedo

mimedo commented Oct 18, 2025

Copy link
Copy Markdown

Thanks for the quick response @xjasonlyu!
When I connect to the SOCKS5 proxy I don't have any internet traffic and I see in the logs:

tun2socks -device tun0 -proxy socks5://[proxy-host]:[proxy-port] -interface eth0
[TCP] dial 1.0.0.1:853: CONNECT: connection not allowed by ruleset"
[UDP] dial 1.1.1.1:53: client handshake: EOF

I tried http-protocoll as well. The proxy provider doesn't need any authentication because my public IP is whitelisted, but I get this message from the logs:

tun2socks -device tun0 -proxy http://[proxy-host]:[proxy-port] -interface eth0
[TCP] dial 1.0.0.1:853: HTTP auth required by proxy"
[UDP] dial 1.0.0.1:53: unsupported operation

So I tried to add credentials but it still didn't work:

tun2socks -device tun0 -proxy http://[username]:[password]@[proxy-host]:[proxy-port] -interface eth0
[TCP] dial 1.0.0.1:853: HTTP connect status: 403 Forbidden
[UDP] dial 1.0.0.1:53: unsupported operation

I want to add that I tried another proxy provider which supported UDP and it worked without any problem. Additionally, I installed Super Proxy on my S21 and connected successfully with SOCKS5 to the proxy. I don't know why it doesn't work with tun2socks.

@mimedo

mimedo commented Oct 20, 2025

Copy link
Copy Markdown

@xjasonlyu I can demonstrate it for you with the Proxy provider I use. Unfortunatelly, I couldn't manage to get it working.

@SuzukiHonoka SuzukiHonoka force-pushed the feat/add-option-disable-udp-fork branch from 8b6032c to a8e572b Compare December 1, 2025 06:24
@mimedo

mimedo commented Dec 1, 2025

Copy link
Copy Markdown

@SuzukiHonoka I see this feature was merged. How is the command to start a connection without UDP?

@SuzukiHonoka

Copy link
Copy Markdown
Contributor Author

@SuzukiHonoka I see this feature was merged. How is the command to start a connection without UDP?

It was not merged yet, if you want to try this, check my fork version of tun2socks, you'll need to compile the binary yourself.

@github-actions github-actions Bot added the Stale label Jan 31, 2026
@github-actions github-actions Bot closed this Feb 7, 2026
@xjasonlyu xjasonlyu removed the Stale label Feb 16, 2026
@xjasonlyu xjasonlyu reopened this Feb 16, 2026
@xjasonlyu xjasonlyu added the pending Waiting for further review label Feb 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request pending Waiting for further review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants