SagerNet / SagerNet/sing-box

TProxy bind nonlocal address may collide with other process

Open
#3,646 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Go
Stars
38.2k
Forks
4.6k
Avg merge
19d 15h
Merged PRs (30d)
1

Description

Operating system

Linux

System version

nixos unstable

Installation type

Original sing-box Command Line

If you are using a graphical client, please provide the version of the client.

No response

Version
v1.12.13
Description

To build a tproxy, we will create a udp listener with ip_transparency option set. And we send the packet received locally to remote. When we received remote packet we send the packet back to local client. However we must bind to nonlocal address the same as remote server address, which set the src address of IP packet to remote address. And this nonlocal address port may collide with the port of other process. I mean another process has used this port. This will lead to a address already in use error.

For example:
Process 1: listening on 0.0.0.0:53

Process 2 tproxy listening on 8900: suppose we received a udp request to 1.1.1.1:53.

UPLOAD traffic:
127.0.0.1:12345 -> TProxy(0.0.0.0:8900) -> 1.1.1.1:53

DOWNLOAD traffic:
127.0.0.1:12345 <- -sing-box( create a new udp socket bound to 1.1.1.1:53 ) <- 1.1.1.1:53

However this creates new udp socket bound to 1.1.1.1:53 will collide with Process 1

Reproduction

a dns server listening on 0.0.0.0:53

sing-box tproxy listening on 8900 with route table properly set

use curl https://baidu.com --dns-servers 114.114.114.114 -v to make dns request and it failed

Logs
+0800 2025-12-25 22:16:03 ERROR [2669416965 5.50s] router: process DNS packet: listen udp 114.114.114.114:53: bind: address already in use
Supporter
Integrity requirements
  • I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
  • I confirm that I have provided the server and client configuration files and process that can be reproduced locally, instead of a complicated client configuration file that has been stripped of sensitive data.
  • I confirm that I have provided the simplest configuration that can be used to reproduce the error I reported, instead of depending on remote servers, TUN, graphical interface clients, or other closed-source software.
  • I confirm that I have provided the complete configuration files and logs, rather than just providing parts I think are useful out of confidence in my own intelligence.

Contributor guide

No contributing guide indexed for this repository

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.

Research direction

No source file or test is named in the report. Start by reproducing the TProxy UDP case with another process listening on 0.0.0.0:53, then trace the path that handles the remote DNS response and creates the nonlocal UDP socket. Done means the reproduced request no longer fails with an address-already-in-use error.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, linux
Domain
cli, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.