Proposal: Add Nowhere protocol support to sing-box

Hello,

I would like to ask whether you would be interested in accepting support for the Nowhere protocol in sing-box.

I have already implemented a prototype integration in my sing-box fork:

• sing-box integration: https://github.com/ohmycggk/sing-box
• Go protocol implementation: https://github.com/ohmycggk/nowhere-go
• Original Nowhere implementation and protocol specification: https://github.com/NodePassProject/Nowhere

About Nowhere

Nowhere is a proxy protocol designed around independent uplink and downlink carriers.

Instead of requiring both directions of a connection to use the same transport, the client can independently select the carrier used for:

• uplink traffic
• downlink traffic

The currently supported carriers are:

• TLS over TCP
• QUIC

This produces four possible carrier combinations:

Uplink	Downlink
TLS/TCP	TLS/TCP
QUIC	QUIC
TLS/TCP	QUIC
QUIC	TLS/TCP

This asymmetric design can be useful on networks where the uplink and downlink have different characteristics or restrictions. For example, QUIC may work well in one direction while TLS/TCP is more stable in the other direction.

The protocol supports both TCP and UDP proxy flows. Mixed-carrier connections are paired at the protocol layer so that the uplink and downlink can use different physical transports while still representing one logical connection.

Other protocol characteristics include:

• native TLS/TCP and QUIC carriers
• independent uplink and downlink carrier selection
• TCP and UDP proxying
• mixed-carrier flow pairing
• connection-bound authentication using TLS exporter material
• typed target addresses and setup results
• protocol-level fragmentation and reassembly for UDP traffic
• client and server implementations

Go implementation

I created nowhere-go as a reusable Go implementation of the protocol.

It contains both:

• outbound/client support
• inbound/server support

The library handles the Nowhere wire protocol and session state, while the host application remains responsible for platform-specific components such as:

• dialers
• TLS configuration
• QUIC implementation
• certificates
• routing
• inbound and outbound configuration schemas

The library does not import sing-box and is intended to keep the protocol implementation separated from the host integration.

Current sing-box integration

I have implemented a prototype integration in my fork, including the corresponding sing-box inbound/outbound adapters and configuration handling.

The integration reuses sing-box components where possible, including its dialer, router, TLS, QUIC, and connection lifecycle infrastructure, rather than introducing a second networking stack.

Before preparing a formal pull request, I would like to confirm:

1. Would Nowhere protocol support be acceptable for upstream sing-box?
2. Would you prefer the protocol implementation to remain in the external nowhere-go module, or be implemented directly inside the sing-box repository?
3. Should an initial pull request include both inbound and outbound support, or would you prefer outbound support first?
4. Are there any architectural, configuration, dependency, testing, or maintenance requirements that should be addressed before submitting the pull request?

I am willing to maintain the integration, add interoperability tests against the original Rust implementation, and adjust the implementation to match sing-box conventions.

Thank you for your time.

Start by reviewing the prototype sing-box integration and the reusable nowhere-go implementation, then compare their inbound/outbound adapters and configuration handling with sing-box conventions. Resolve whether the implementation should remain external and whether the initial scope includes both directions. Done means the upstream architecture, dependency, testing, and maintenance requirements are agreed before a formal pull request.