You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary
Allow AdGuard Home to read a custom HTTP header (e.g., X-Client-ID or X-Forwarded-Client-ID) in DoH requests when behind a reverse proxy/relay. This would enable easy per-client identification without requiring a full second AdGuard Home instance on the local network.
Motivation
When running AdGuard Home (AGH) as a public DoH endpoint behind a generic reverse proxy (like Nginx, Caddy, or dnsproxy), all traffic from a single network is logged as one client (the public IP of the network).
Current methods for per-client identification are complicated:
Running a second AGH instance: This is high-overhead and redundant.
Using the /dns-query/ path: This requires complex, per-device configuration and is often impossible on simple clients (e.g., smart TVs).
A client relay (like dnsproxy or a sophisticated router) can easily insert a custom HTTP header containing the local client's IP or a generated ID before forwarding to the public DoH server. Implementing a feature to read and trust this header would simplify secure, per-client identification for a large segment of the self-hosting community, replicating the seamless client visibility offered by services like NextDNS.
Proposed Solution
Add a configuration option to AdGuardHome.yaml that specifies a custom HTTP header field to check for client identification on proxied DoH requests:
1. Configuration Change:
# AdGuardHome.yaml
dns:
# ... other settings ...
# New setting to specify a custom HTTP header for client ID
doh_client_id_header: 'X-Forwarded-Client-ID'
2. Behavior:
If doh_client_id_header is set, AGH checks for the value of that header in the incoming DoH request.
If the header is present and the value corresponds to a configured AGH Client ID, the request is logged and processed for that client.
If the header is missing or the value is unrecognized, the request falls back to standard client identification (IP/subnet).
This feature would offer a clean, low-overhead, standards-compliant way to get per-client logging.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
Allow AdGuard Home to read a custom HTTP header (e.g., X-Client-ID or X-Forwarded-Client-ID) in DoH requests when behind a reverse proxy/relay. This would enable easy per-client identification without requiring a full second AdGuard Home instance on the local network.
Motivation
When running AdGuard Home (AGH) as a public DoH endpoint behind a generic reverse proxy (like Nginx, Caddy, or dnsproxy), all traffic from a single network is logged as one client (the public IP of the network).
Current methods for per-client identification are complicated:
A client relay (like dnsproxy or a sophisticated router) can easily insert a custom HTTP header containing the local client's IP or a generated ID before forwarding to the public DoH server. Implementing a feature to read and trust this header would simplify secure, per-client identification for a large segment of the self-hosting community, replicating the seamless client visibility offered by services like NextDNS.
Proposed Solution
Add a configuration option to AdGuardHome.yaml that specifies a custom HTTP header field to check for client identification on proxied DoH requests:
1. Configuration Change:
2. Behavior:
This feature would offer a clean, low-overhead, standards-compliant way to get per-client logging.
Beta Was this translation helpful? Give feedback.
All reactions