[Bug]: The DNS value in the WireGuard configuration is not being passed to the client

[mustfqyl]

Before you submit

• I searched existing issues and did not find the same problem.
• I am using the latest available PasarGuard version, or I included the exact version below.

PasarGuard version

latest

Installation type

Docker Compose

What happened?

This issue was raised previously and closed as resolved, but the problem persists; unless you manually enter the DNS settings on the client, there is absolutely no internet connection. (In versions prior to v5.1.0, manually entering the DNS value in the server configuration would pass it on to the client; this no longer happens with latest version.)

Steps to reproduce

Create the WireGuard configuration, then you will have to manually enter the DNS value; the DNS value you added will not carry over when you transfer the provided config to the client.

Expected behavior

The DNS parameter must be sent to the client.

Logs and error messages

xx

Environment

OS:
Database: SQLite / MySQL / PostgreSQL / TimescaleDB
Python version:
Node.js version:
Browser:
Reverse proxy / CDN:

Relevant configuration

Screenshots or videos

Additional context

No response

[dr-hoseyn]

I couldn't reproduce this issue on v5.4.1.

The DNS value must be configured under Host → WireGuard overrides → DNS, not in the WireGuard Core configuration. When configured there, the generated wireguard:// URI, QR code, and .conf file all include the DNS value correctly.

This was previously a real bug: the DNS parameter was explicitly removed from the generated URI. It was fixed in commit 2aa51cf.

Please provide the following if the problem still occurs:

• The exact PasarGuard version or Docker image tag
• The raw /links and /wireguard subscription outputs
• The saved Host configuration, especially wireguard_overrides
• Confirmation of where the DNS value was entered

If DNS was added directly to the WireGuard Core JSON, it is currently ignored because DNS is a per-host override. In that case, this may be a UX/documentation issue rather than a subscription-generation bug.

[mustfqyl]

There used to be no such problem—we would simply add the DNS value directly to the config section, and it would work flawlessly with the subscription. Then updates came, and it broke completely.

Now, as you mentioned, when I enter the DNS settings in the “Host” section, it works—I can copy the config and use it in the WireGuard client. But when I add it via the subscription link in the Happ client, the ping shows up, yet there’s no stable data flow once connected.

Also, once the MTU and Keep Alive values in the “Network Settings” section under “Host” are saved, you can’t completely delete them—the old saved values immediately revert. This is a frontend bug.

Also, why is the value I already specified in the config section being ignored? This is ridiculous!
Maybe I’m missing something—I’m attaching the JSON version of the WireGuard config that comes via the subscription link in the Happ client below;

{
"dns" : {
"servers" : [
"1.1.1.1",
"1.0.0.1"
]
},
"inbounds" : [
{
"listen" : "127.0.0.1",
"port" : 10808,
"protocol" : "socks",
"settings" : {
"allowTransparent" : false,
"auth" : "noauth",
"udp" : true
},
"sniffing" : {
"destOverride" : [
"http",
"tls"
],
"enabled" : true,
"routeOnly" : false
},
"tag" : "socks"
},
{
"listen" : "127.0.0.1",
"port" : 10809,
"protocol" : "http",
"settings" : {
"allowTransparent" : false,
"auth" : "noauth",
"udp" : true
},
"sniffing" : {
"destOverride" : [
"http",
"tls"
],
"enabled" : true,
"routeOnly" : false
},
"tag" : "http"
}
],
"log" : {
"access" : "/Users/mac/Library/Group Containers/group.su.ffg.happ/Library/Application Support/Xray/logs/access.log",
"dnsLog" : true,
"loglevel" : "Error"
},
"outbounds" : [
{
"protocol" : "wireguard",
"settings" : {
"address" : [
"10.0.0.2/32"
],
"domainStrategy" : "ForceIP",
"mtu" : 1280,
"peers" : [
{
"allowedIPs" : [
"0.0.0.0/0"
],
"endpoint" : "de-fra-01.domain.com:444",
"keepAlive" : 25,
"publicKey" : "obw3LObr46ncGUhKc/D0keFdJl5PtqImQG3TM5c5lgQ="
}
],
"remoteDNS" : [
"1.1.1.1"
],
"secretKey" : "8O0wQIuDVCdSfYydMsmrc45bAgqwnG9OsZ2jsqeFUFM="
},
"tag" : "proxy"
},
{
"protocol" : "freedom",
"tag" : "DIRECT"
},
{
"protocol" : "blackhole",
"tag" : "BLOCK"
}
],
"remarks" : "Frankfurt",
"routing" : {
"domainStrategy" : "AsIs",
"rules" : []
}
}

[dr-hoseyn]

Thanks for the additional details.

The JSON you attached shows that the DNS value is being passed correctly:

• dns.servers contains 1.1.1.1 and 1.0.0.1
• the WireGuard outbound contains remoteDNS: ["1.1.1.1"]

So the original issue—DNS being omitted from the generated client configuration—is not reproduced here. The fact that the configuration works in the official WireGuard client but has unstable traffic in Happ points to a separate Happ/Xray compatibility or runtime issue, rather than the DNS subscription-generation bug.

Please provide:

• the exact Happ version and platform
• the Xray-core version bundled with Happ, if available
• the Xray error/access logs from a failed session
• the raw PasarGuard Xray subscription response before Happ transforms or imports it

Regarding the DNS value in the WireGuard Core configuration: the current design separates server-interface configuration from client-facing settings. DNS, MTU, KeepAlive, and similar client values are taken from Host → WireGuard overrides. Silently accepting a DNS value in the Core JSON while not using it for subscriptions can certainly be improved as a UX/documentation issue, but it is separate from the fixed DNS omission bug.

I also cannot confirm the MTU/KeepAlive clearing issue from the attached JSON. The current form and API paths are intended to clear those overrides when the fields are emptied. Please open a separate issue for that behavior and include a short screen recording, the exact PasarGuard version, and the request/response payload for PUT /api/host/{id} so it can be reproduced reliably.

[mustfqyl]

thanks for information

Happ
Xray: 26.7.28
App: 5.6.0
API: 3.19.0
Platforms: IOS, MacOS

Logs;

[17.09.2026 13:31:42] XrayCoreStart - {"success":true} app: v5.6.0
2026/09/17 13:31:50.269914 [Error] IPC error -22: failed to set endpoint de-fra-01.domain.com:444: app/dns: returning nil for domain de-fra-01.domain.com > app/dns: record not found
2026/09/17 13:31:58.270506 [Error] IPC error -22: failed to set endpoint de-fra-01.domain.com:444: app/dns: returning nil for domain de-fra-01.domain.com > app/dns: record not found
2026/09/17 13:32:06.274618 [Error] IPC error -22: failed to set endpoint de-fra-01.domain.com:444: app/dns: returning nil for domain de-fra-01.domain.com > app/dns: record not found
2026/09/17 13:32:14.278493 [Error] IPC error -22: failed to set endpoint de-fra-01.domain.com:444: app/dns: returning nil for domain de-fra-01.domain.com > app/dns: record not found