[Feature Request] Add a possibility to use Unix Domain sockets #3186

New issue

Open

opened 2026-03-04 03:09:14 -05:00 by deekerman · 0 comments

deekerman commented

2026-03-04 03:09:14 -05:00

Owner

Originally created by @DavidOsipov on GitHub (Nov 13, 2021).

Dear developers,

I would like to request a feature - a possibility for Adguard Home to use Unix domain sockets.

Desired behavior:

A possibility to change bind_host, upstream_dns, bootstrap_dns, port_https, port_dns_over_tls, port_dns_over_quic to listen to inputs like https+unix:/path/to/a/socket; http+unix:/path/to/a/socket; quic+unix:/path/to/a/socket, dns+unix:/path/to/a/socket (the last two are only possible to use with Unix domain Datagram sockets | SOCK_DGRAM)

In other words, Adguard home would be able to receive requests via Unix domain sockets and contact an upstream server (Unbound for example) also via a Unix domain socket.

Implications:

In general, Unix domain sockets are 1.5-2 times faster, than IP sockets. The possibility to strip TLS or QUIC layer on a webserver like Nginx and then forward traffic through a Unix domain socket to Adguard home could introduce benefits like there would be no need to do a TLS handshakes several times, traffic won't be susceptible to standard routing schemes of IP sockets, which would increase performance and decrease latency. Most probably, the improvements would be much higher on high load servers or low-performance instances such as small VPS.

The exact numbers on possible performance benefit I do not possess, but let me cite Eli Bendersky:

For very small message sizes we're getting back to latency-dominated performance, so UDS is considerably faster (more than 2x the number of packets per second compared to TCP). In most cases I'd say that the latency measurements are more important - they're more applicable to things like RPC servers and databases.

"Unix domain sockets in Go" Eli Bendersky's website

As DNS packet size is also quite small, introducing this feature could greatly benefit performance.

Nginx webserver already has configurations, which allow to accept, decode, cache and forward DNS, DoT, DoH traffic - in other words, to strip encryption layer and forward requests to an upstream server (here and here). And according to @ameshkov in this discussion , using a reverse proxy in front of Adguard Home is the recommended way:

...it is always possible to configure a reverse proxy like nginx or caddy in front of AGH. This is actually the recommended way.

Possible complications:

As @ainar-g mentioned in the discussion, Adguard home depends on a dnsproxy module, which, most probably, would be heavily rewritten or replaced in the future. Unfortunately, I'm not a developer and can't help you by writing code, so it's up to you to decide whether or when to implement this feature, it could as well remain in the backlog until it becomes feasible to implement. I would just again cite Eli Bendersky:

...And the API of UDS and TCP sockets is so similar that the cost of supporting both interchangeably is quite small.

"Unix domain sockets in Go" Eli Bendersky's website

Originally created by @DavidOsipov on GitHub (Nov 13, 2021). Dear developers, I would like to request a feature - a possibility for Adguard Home to use Unix domain sockets. <h2>Desired behavior:</h2> A possibility to change `bind_host`, `upstream_dns`, `bootstrap_dns`, `port_https`, `port_dns_over_tls`, `port_dns_over_quic` to listen to inputs like `https+unix:/path/to/a/socket`; `http+unix:/path/to/a/socket`; `quic+unix:/path/to/a/socket`, `dns+unix:/path/to/a/socket` (the last two are only possible to use with Unix domain Datagram sockets | [SOCK_DGRAM](https://man7.org/linux/man-pages/man7/unix.7.html)) In other words, Adguard home would be able to receive requests via Unix domain sockets and contact an upstream server ([Unbound](https://github.com/NLnetLabs/unbound) for example) also via a Unix domain socket. <h2>Implications:</h2> In general, Unix domain sockets are [1.5-2 times faster](https://redis.io/topics/benchmarks), than IP sockets. The possibility to strip TLS or QUIC layer on a webserver like Nginx and then forward traffic through a Unix domain socket to Adguard home could introduce benefits like there would be no need to do a TLS handshakes several times, traffic won't be susceptible to standard routing schemes of IP sockets, which would increase performance and decrease latency. Most probably, the improvements would be much higher on high load servers or low-performance instances such as small VPS. The exact numbers on possible performance benefit I do not possess, but let me cite Eli Bendersky: > For very small message sizes we're getting back to latency-dominated performance, so UDS is considerably faster (more than 2x the number of packets per second compared to TCP). In most cases I'd say that the latency measurements are more important - they're more applicable to things like RPC servers and databases. **"Unix domain sockets in Go" [Eli Bendersky's website](https://eli.thegreenplace.net/2019/unix-domain-sockets-in-go/)** As DNS packet size is also quite small, introducing this feature could greatly benefit performance. Nginx webserver already has configurations, which allow to accept, decode, cache and forward DNS, DoT, DoH traffic - in other words, to strip encryption layer and forward requests to an upstream server ([here](https://www.nginx.com/blog/using-nginx-as-dot-doh-gateway/) and [here](https://github.com/TuxInvader/nginx-dns)). And according to @ameshkov in this [discussion ](https://github.com/AdguardTeam/AdGuardHome/issues/3240), using a reverse proxy in front of Adguard Home is the recommended way: > ...it is always possible to configure a reverse proxy like nginx or caddy in front of AGH. This is actually the recommended way. <h2>Possible complications:</h2> As @ainar-g mentioned in [the discussion](https://github.com/AdguardTeam/AdGuardHome/discussions/3810), Adguard home depends on a `dnsproxy` module, which, most probably, would be heavily rewritten or replaced in the future. Unfortunately, I'm not a developer and can't help you by writing code, so it's up to you to decide whether or when to implement this feature, it could as well remain in the backlog until it becomes feasible to implement. I would just again cite Eli Bendersky: > ...And the API of UDS and TCP sockets is so similar that the cost of supporting both interchangeably is quite small. **"Unix domain sockets in Go" [Eli Bendersky's website](https://eli.thegreenplace.net/2019/unix-domain-sockets-in-go/)**