Is there a reason I'm unable to access the DelugeVPN web interface remotely using Unraid's built-in Wireguard VPN? I recently installed it on my Unraid NAS (7.2.3) and it's working fine (using a Wireguard connection to ProtonVPN). I use Wireguard to reach my NAS remotely, and have no problem accessing the webgui and all my other Docker apps. But I can only reach DelugeVPN from within the LAN, not via Wireguard--the DelugeVPN webgui never loads and I get ERR_CONNECTION_TIMED_OUT.

15 minutes ago, bar_foo said:

Is there a reason I'm unable to access the DelugeVPN web interface remotely using Unraid's built-in Wireguard VPN? I recently installed it on my Unraid NAS (7.2.3) and it's working fine (using a Wireguard connection to ProtonVPN). I use Wireguard to reach my NAS remotely, and have no problem accessing the webgui and all my other Docker apps. But I can only reach DelugeVPN from within the LAN, not via Wireguard--the DelugeVPN webgui never loads and I get ERR_CONNECTION_TIMED_OUT.

You need to add your remote subnet to the LAN_NETWORK variable.

10 minutes ago, strike said:

You need to add your remote subnet to the LAN_NETWORK variable.

Thanks--would that be the one assigned under "Peer tunnel address" in the VPN settings?

If so, since that is in a different subnet from the LAN addresses, does LAN_NETWORK accept multiple subnets, or only a single, contiguous CIDR range?

34 minutes ago, bar_foo said:

Thanks--would that be the one assigned under "Peer tunnel address" in the VPN settings?

If so, since that is in a different subnet from the LAN addresses, does LAN_NETWORK accept multiple subnets, or only a single, contiguous CIDR range?

I haven't really tried it myself, but add both to be safe (your remote LAN and the one in VPN settings), or just try one of them at a time if you want. LAN_NETWORK accepts multiple comma-separated CIDR ranges

46 minutes ago, strike said:

I haven't really tried it myself, but add both to be safe (your remote LAN and the one in VPN settings), or just try one of them at a time if you want. LAN_NETWORK accepts multiple comma-separated CIDR ranges

Got it. I tried with a space separating the ranges and it didn't work, but I'll give the comma a shot.

I have the same issue as the one presented here: [help needed] binhex-qbittorrentvpn + PIA : r/unRAID
It started some time in the past few months. Everything was working great with wireguard before that, and openvpn before that.

I have tried the following which produced the same result
- Deleting the /config/wireguard/wg0.conf file
- Switching to USERSPACE_WIREGUARD = yes
- Disabling the Tailscale container integration
- Switching to openvpn then back to wireguard
- Switching to a different PIA endpoint

Nothing that I have found in this thread, nor in the VPN nor VPN Docker FAQ pages have helped. No matter what the configuration, it seems that the Address and PublicKey fields are never populated in the produced Wireguard config file.

I've attached the supervisord file and the unraid command execution with PID censored. Any help is greatly appreciated, thank you!

command_execution.txt supervisord.txt

Edited December 31, 2025Dec 31 by elys_k
duplicate image

3 hours ago, elys_k said:

No matter what the configuration, it seems that the Address and PublicKey fields are never populated in the produced Wireguard config file.

This indeed seems to be the issue. I don't use PIA or wg, but is the PIA wg generated token for an endpoint always the same? If so, you can just edit the wg0.conf file yourself and add the token to the public key. You should, in any case, delete the wg0.conf file again since you posted your private key in the screenshot.

On 10/29/2025 at 3:17 PM, Random Mike said:

I keep getting a output message as follows:

DEBG 'watchdog-script' stderr output:

/usr/lib/python3.13/site-packages/deluge/pluginmanagerbase.py:16: UserWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html. The pkg_resources package is slated for removal as early as 2025-11-30. Refrain from using this package or pin to Setuptools<81.

import pkg_resources

Binhex confirmed on this issue that the problem is on Deluge's side, nothing they can do.

And Deluge https://dev.deluge-torrent.org/ticket/3252 seems to know about it, though looks low on the priority.

Suddenly in the past week, my binhex-delugevpn has stopped working.

When I first noticed it and attempted to login, I was unable to (told my password was incorrect). On a hunch, I punched in the default password for the web UI, and that worked--but ALL the settings and active torrents had disappeared. It was like deluge has been reset to 0.

So I turned it off (shut down the docker container) and turned it back on, and in this instance, the web UI wouldn't even start.

These are the docker logs:

[info] bo-bolivia-pf.privacy.network
[info] is.privacy.network
[info] qatar.privacy.network
[info] spain.privacy.network
[info] uk-2.privacy.network
[info] ro.privacy.network
[info] ca-vancouver.privacy.network
[info] uk-manchester.privacy.network
[info] br.privacy.network
[info] sofia.privacy.network
[info] kr-south-korea-pf.privacy.network
[info] bahamas.privacy.network
[info] srilanka.privacy.network
[info] au-australia-so.privacy.network
[info] france.privacy.network
[info] morocco.privacy.network
[info] austria.privacy.network
[info] italy.privacy.network
[info] bangladesh.privacy.network
[info] swiss.privacy.network
[info] monaco.privacy.network
[info] saudiarabia.privacy.network
[info] uk-southampton.privacy.network
[info] sanjose.privacy.network
[info] ireland.privacy.network
[info] bogota.privacy.network
[info] man.privacy.network
[info] montenegro.privacy.network
[info] de-frankfurt.pvt.site
[info] de-berlin.pvt.site
2026-01-06 09:46:27,667 DEBG 'start-script' stdout output:
[info] Successfully downloaded PIA json to generate token for wireguard from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'
2026-01-06 09:46:27,670 DEBG 'start-script' stdout output:
[info] Successfully generated PIA token for wireguard
[debug] PIA generated 'token' for wireguard is '<REDACTED>'
2026-01-06 09:46:27,846 DEBG 'start-script' stdout output:
[debug] PIA generated 'token' for port forwarding is '<REDACTED>'
[debug] PIA assigned incoming port is '42122'
[debug] PIA port forward assigned expires on '2026-03-10T02:46:27.808370111Z'
2026-01-06 09:46:27,847 DEBG 'start-script' stdout output:
[debug] Running infinite while loop to keep assigned incoming port for PIA live...
2026-01-06 09:46:28,010 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port
2026-01-06 09:46:28,847 DEBG 'watchdog-script' stdout output:
[debug] Checking we can resolve name 'www.google.com' to address...
2026-01-06 09:46:28,891 DEBG 'watchdog-script' stdout output:
[debug] DNS operational, we can resolve name 'www.google.com' to address '142.250.139.106 142.250.139.103 142.250.139.104 142.250.139.147 142.250.139.105 142.250.139.99'
2026-01-06 09:46:28,892 DEBG 'watchdog-script' stdout output:
[debug] Waiting for iptables chain policies to be in place...
2026-01-06 09:46:28,895 DEBG 'watchdog-script' stdout output:
[debug] iptables chain policies are in place
2026-01-06 09:46:28,895 DEBG 'watchdog-script' stdout output:
[info] Deluge listening interface IP 0.0.0.0 and VPN provider IP 10.30.130.140 different, marking for reconfigure
2026-01-06 09:46:28,900 DEBG 'watchdog-script' stdout output:
[info] Deluge not running
2026-01-06 09:46:28,901 DEBG 'watchdog-script' stdout output:
[info] Deluge Web UI not running
2026-01-06 09:46:28,905 DEBG 'watchdog-script' stdout output:
[info] Privoxy not running
2026-01-06 09:46:28,905 DEBG 'watchdog-script' stdout output:
[info] Deluge incoming port 6890 and VPN incoming port 42122 different, marking for reconfigure
2026-01-06 09:46:28,906 DEBG 'watchdog-script' stdout output:
[info] Attempting to start Deluge...
[info] Removing deluge pid file (if it exists)...
2026-01-06 09:46:29,206 DEBG 'watchdog-script' stdout output:
[info] Deluge key 'listen_interface' currently has a value of '10.27.248.138'
[info] Deluge key 'listen_interface' will have a new value '10.30.130.140'
[info] Writing changes to Deluge config file '/config/core.conf'...
2026-01-06 09:46:29,380 DEBG 'watchdog-script' stdout output:
[info] Deluge key 'outgoing_interface' currently has a value of 'wg0'
[info] Deluge key 'outgoing_interface' will have a new value 'wg0'
[info] Writing changes to Deluge config file '/config/core.conf'...
2026-01-06 09:56:28,209 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port
2026-01-06 10:06:28,412 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port
2026-01-06 10:16:28,614 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port
2026-01-06 10:26:28,814 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port
2026-01-06 10:36:29,012 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port

Notice the timestamps in particular: 10 minutes start passing between logging outputs, and the web UI still hasn't come up, but no error messages that I can tell.

I haven't changed anything in the past week--nothing in the Unraid app configuration, nor in the deluge configuration files directly. Deluge has been happily seeding away up until a few days ago, so I'm not sure what could have changed, or even where to look. Any help would be greatly appreciated.

Figured it out--somehow, the web.conf had bloated to over 78MB (yes, MB) and so was preventing deluge from starting. Deleting it and letting deluge recreate it restored everything from the previous working state (except the web UI password, which I simply reset myself).

I have no idea why or how the file got so bloated (even web.conf.bak was over 40MB), so I guess that's something I'll keep an eye on going forward.

2 hours ago, magsol said:

Figured it out--somehow, the web.conf had bloated to over 78MB (yes, MB) and so was preventing deluge from starting. Deleting it and letting deluge recreate it restored everything from the previous working state (except the web UI password, which I simply reset myself).

I have no idea why or how the file got so bloated (even web.conf.bak was over 40MB), so I guess that's something I'll keep an eye on going forward.

There are a few files that, depending on what you are using with Deluge, can grow extremely large.

In your appdata/config directory, there is a

"sessions": {

section in web.conf. This will fill indefinitely with logins made into the WebUI unless you log out.

The problem is you can't just delete it outright, as there are other settings in there as well. In my scripts, I log out of the webui every time I exit cross-seed (a program I develop) or when I run scripts that log in and sort my labels and releases. This keeps it somewhat small, but still slightly larger than I'd prefer.

They DO expire after 12 or so hours, but I do not believe they are purged until rebooting the webui, or possibly the entire container. There is no real purpose in keeping those sessions past your usage of the webui, and hitting X doesn't log them out or remove them. (They are in JSON, btw.)

{

"file": 2,

"format": 1

}{

"base": "/",

"cert": "ssl/daemon.cert",

"default_daemon": "",

"enabled_plugins": [],

"first_login": false,

"https": false,

"interface": "0.0.0.0",

"language": "",

"pkey": "ssl/daemon.pkey",

"port": 8112,

"pwd_salt": "[REDACTED]",

"pwd_sha1": "[REDACTED]",

"session_timeout": 3600,

"sessions": {

"0013d2914ccf848be837e5f367e18a9686a5d496f51d1727bd5ff30fe1952a4f": {

"expires": 1726879504.0,

"level": 10,

"login": "admin"

},

"0067540478b0a1e647ec8a080b9581464690ee0ed8ea2fb07b0c1eb4291466d1": {

"expires": 1759643482.0,

"level": 10,

"login": "admin"

},

"00b94269d123873402aac2e866081b6688fc798ed6f3e7ad41b6cb8dae364564": {

"expires": 1731076670.0,

"level": 10,

"login": "admin"

},

.......and many, many more. It has been around a year since I last pruned it, and I have 1852 entries. The primary issue is that there have been PRs and work I've done for the Starr Apps, work I've done refactoring Deluge's client in cross-seed, and several scripts I mentioned. It's impossible to know when the time has come for them to be logged out properly in the automation apps, and turning restarts or container crashes don't clean up

The good news is my entire web.conf is 325KB - nothing to worry about. Before I realized this issue, reaching out to Linuxserver, fixing it in cross-seed, and the starr apps - I believe I left binhex a message on Discord, but he doesn't check often, I was getting web.conf files in the range of 30-50MB, screwing up removing the objects in the sessions array, and just having a hard time.

Perhaps I'll write a script this weekend that prunes them and keeps a single active connection, and removes idle connections that have not received commands for some duration. It could easily be incorporated into the LSIO and binhex containers as my other scripts have...

@binhex If you can find some time, I'd love to have a chat with you on Discord. I think there are a few things I'd consider bugs, as well as the session thing, and other daemon and web process separation that can lead to issues for users.

Let me know.

I've just recently started having recurring issues with binhex-delugevpn stopping to work.

I'm not sure how to debug this any further.

It will work for a short time then stop working (ProtonVPN wireguard), see logs:

2026-01-17 21:04:39,111 DEBG 'start-script' stdout output:

[debug] ProtonVPN assigned incoming port is '55114'

2026-01-17 21:05:04,976 DEBG 'watchdog-script' stdout output:

[debug] Checking we can resolve name 'www.google.com' to address...

2026-01-17 21:05:35,013 DEBG 'watchdog-script' stdout output:

[debug] Having issues resolving name 'www.google.com'

[debug] Retrying in 5 secs...

[debug] 11 retries left

2026-01-17 21:06:10,051 DEBG 'watchdog-script' stdout output:

[debug] Having issues resolving name 'www.google.com'

[debug] Retrying in 5 secs...

[debug] 10 retries left

2026-01-17 21:06:45,091 DEBG 'watchdog-script' stdout output:

[debug] Having issues resolving name 'www.google.com'

[debug] Retrying in 5 secs...

[debug] 9 retries left

2026-01-17 21:07:05,237 DEBG 'watchdog-script' stdout output:

[debug] DNS operational, we can resolve name 'www.google.com' to address '142.250.129.105 142.250.129.106 142.250.129.147 142.250.129.99 142.250.129.103 142.250.129.104'

Now it has completely failed and won't pass the retry.

I have tried changing my wg config to a different server and again, it works briefly then stops working.

Can anyone please help me debug this? I haven't changed anything, it has worked flawlessly for months.

I note this:

2026-01-17 21:14:00,734 DEBG 'watchdog-script' stdout output:

[info] DNS failure, creating file '/tmp/dnsfailure' to indicate failure...

Edited January 17Jan 17 by sevo

2 hours ago, sevo said:

I've just recently started having recurring issues with binhex-delugevpn stopping to work.

I'm not sure how to debug this any further.

It will work for a short time then stop working (ProtonVPN wireguard), see logs:

2026-01-17 21:04:39,111 DEBG 'start-script' stdout output:

[debug] ProtonVPN assigned incoming port is '55114'

2026-01-17 21:05:04,976 DEBG 'watchdog-script' stdout output:

[debug] Checking we can resolve name 'www.google.com' to address...

2026-01-17 21:05:35,013 DEBG 'watchdog-script' stdout output:

[debug] Having issues resolving name 'www.google.com'

[debug] Retrying in 5 secs...

[debug] 11 retries left

2026-01-17 21:06:10,051 DEBG 'watchdog-script' stdout output:

[debug] Having issues resolving name 'www.google.com'

[debug] Retrying in 5 secs...

[debug] 10 retries left

2026-01-17 21:06:45,091 DEBG 'watchdog-script' stdout output:

[debug] Having issues resolving name 'www.google.com'

[debug] Retrying in 5 secs...

[debug] 9 retries left

2026-01-17 21:07:05,237 DEBG 'watchdog-script' stdout output:

[debug] DNS operational, we can resolve name 'www.google.com' to address '142.250.129.105 142.250.129.106 142.250.129.147 142.250.129.99 142.250.129.103 142.250.129.104'

Now it has completely failed and won't pass the retry.

I have tried changing my wg config to a different server and again, it works briefly then stops working.

Can anyone please help me debug this? I haven't changed anything, it has worked flawlessly for months.

I note this:

2026-01-17 21:14:00,734 DEBG 'watchdog-script' stdout output:

[info] DNS failure, creating file '/tmp/dnsfailure' to indicate failure...

Do you use pfsense with snort/suricata or any other form of IDS/IPS? I had this issue a few months ago and it was due to snort adding a new rule, blocking delugevpn.

7 minutes ago, strike said:

Do you use pfsense with snort/suricata or any other form of IDS/IPS? I had this issue a few months ago and it was due to snort adding a new rule, blocking delugevpn.

I don't use any of those :(

I can't figure out why this is happening.

1 minute ago, sevo said:

I don't use any of those :(

I can't figure out why this is happening.

When it stops working, if you restart the container does it work again on first try?

Try changing your name servers in the template to 1.1.1.1,1.0.0.1

If that doesn't work you need to monitor your firewall logs to see if it's blocking.

2 minutes ago, strike said:

When it stops working, if you restart the container does it work again on first try?

Try changing your name servers in the template to 1.1.1.1,1.0.0.1

If that doesn't work you need to monitor your firewall logs to see if it's blocking.

It's sporadic, sometimes it works on first try sometimes it doesn't. I find if I change the wireguard config to another one (i.e. different server) it will work for a short time then stop working. I have just tried an openvpn alternative and it works for a short time then stops also.

I have those name servers set and is also not working.

9 minutes ago, sevo said:

It's sporadic, sometimes it works on first try sometimes it doesn't. I find if I change the wireguard config to another one (i.e. different server) it will work for a short time then stop working. I have just tried an openvpn alternative and it works for a short time then stops also.

I have those name servers set and is also not working.

Then I would check the firewall or anything that has to do with dns, if you use pihole for example. The problem isn't with the VPN server, but something blocks name resolution causing the container not to be able to connect.

7 minutes ago, strike said:

Then I would check the firewall or anything that has to do with dns, if you use pihole for example. The problem isn't with the VPN server, but something blocks name resolution causing the container not to be able to connect.

To be honest I'm not sure how to access firewall logs. My ISP's router software is shit and doesn't really have anything helpful in there.

Here are the full logs: https://paste.passtheheadphones.me/?2452b4a7fd9df0fb#6zDdpN112G5N5jbvaegqVDrDvYvTKBxvHsCuirbSxiP8

It's a strange issue.

It seems to be only with ProtonVPN that this is happening. If I use an alternative VPN provider (e.g. PIA with openvpn) it works fine and as expected. But with the ProtonVPN, I repeatedly get satisfactory start ups with torrents downloading and seeding, but then it will start to do the DNS checks and then it fails and stops.

The only logs I can ever see are these:

2026-01-18 20:15:23,983 DEBG 'watchdog-script' stdout output:

[debug] DNS operational, we can resolve name 'www.google.com' to address '142.250.140.103 142.250.140.147 142.250.140.99 142.250.140.104 142.250.140.106 142.250.140.105'

2026-01-18 20:15:23,983 DEBG 'watchdog-script' stdout output:

[debug] Waiting for iptables chain policies to be in place...

2026-01-18 20:15:23,991 DEBG 'watchdog-script' stdout output:

[debug] iptables chain policies are in place

2026-01-18 20:15:24,000 DEBG 'watchdog-script' stdout output:

[debug] VPN incoming port is 6890

[debug] Deluge incoming port is 6890

[debug] VPN IP is 10.2.0.2

[debug] Deluge IP is 10.2.0.2

2026-01-18 20:15:54,005 DEBG 'watchdog-script' stdout output:

[debug] Checking we can resolve name 'www.google.com' to address...

2026-01-18 20:16:39,059 DEBG 'watchdog-script' stdout output:

[debug] Having issues resolving name 'www.google.com'

[debug] Retrying in 5 secs...

[debug] 11 retries left

Might anyone know if there are some other logs I can check to see what exactly is happening when the failure starts? I am still inclined to think this is a ProtonVPN issue but I would expect it to have been resolved by now.

I need to know my public facing IP address for a tracker I'm getting connected to. Since I feed a specific VPN endpoint into this container, that endpoint won't change.

I open a container console and do curl https://whatismyip.com and get back:

sh-5.3# curl https://whatismyip.com

curl: (6) Could not resolve host: whatismyip.com

I had the network set to a custom network (with all my other containers) and got no response from curl, then I changed to Bridge, and got the response above.

What am I doing wrong?

Interestingly, curl ipinfo.io works just fine... However, I'm getting an IP address returned that doesn't appear to be specified in my `openvpn.ovpn` file. :(

Edited January 22Jan 22 by Free Man

5 minutes ago, Free Man said:

I need to know my public facing IP address for a tracker I'm getting connected to. Since I feed a specific VPN endpoint into this container, that endpoint won't change.

I open a container console and do curl https://whatismyip.com and get back:

sh-5.3# curl https://whatismyip.com

curl: (6) Could not resolve host: whatismyip.com

I had the network set to a custom network (with all my other containers) and got no response from curl, then I changed to Bridge, and got the response above.

What am I doing wrong?

Run this instead:

curl ifconfig.io

On 1/18/2026 at 8:20 PM, sevo said:

It's a strange issue.

It seems to be only with ProtonVPN that this is happening. If I use an alternative VPN provider (e.g. PIA with openvpn) it works fine and as expected. But with the ProtonVPN, I repeatedly get satisfactory start ups with torrents downloading and seeding, but then it will start to do the DNS checks and then it fails and stops.

The only logs I can ever see are these:

2026-01-18 20:15:23,983 DEBG 'watchdog-script' stdout output:

[debug] DNS operational, we can resolve name 'www.google.com' to address '142.250.140.103 142.250.140.147 142.250.140.99 142.250.140.104 142.250.140.106 142.250.140.105'

2026-01-18 20:15:23,983 DEBG 'watchdog-script' stdout output:

[debug] Waiting for iptables chain policies to be in place...

2026-01-18 20:15:23,991 DEBG 'watchdog-script' stdout output:

[debug] iptables chain policies are in place

2026-01-18 20:15:24,000 DEBG 'watchdog-script' stdout output:

[debug] VPN incoming port is 6890

[debug] Deluge incoming port is 6890

[debug] VPN IP is 10.2.0.2

[debug] Deluge IP is 10.2.0.2

2026-01-18 20:15:54,005 DEBG 'watchdog-script' stdout output:

[debug] Checking we can resolve name 'www.google.com' to address...

2026-01-18 20:16:39,059 DEBG 'watchdog-script' stdout output:

[debug] Having issues resolving name 'www.google.com'

[debug] Retrying in 5 secs...

[debug] 11 retries left

Might anyone know if there are some other logs I can check to see what exactly is happening when the failure starts? I am still inclined to think this is a ProtonVPN issue but I would expect it to have been resolved by now.

Resolved my issue by limiting maximum active connections, it was unlimited.

I've been running this for years and it's worked very well.

I recently received notification from ProtonVPN that I'm using a deprecated OpenVPN connection, so I'll need to reconfigure. They recommend going to WireGuard, but can support an OVPN config if needed.

I created a WireGuard config file at my account page from them and downloaded it, but it's downloaded as a .conf file, not a .wg0. Also, there was no /config/wireguard directory for me to put it in, so I created it and dropped the .conf file there. I renamed the /config/openvpn directory to /config/openvpn-OLD so it wouldn't get used.

When I tried to restart the container, it complained that

2026-02-21 15:52:31.671515 [warn] VPN_CLIENT not defined (via -e VPN_CLIENT), defaulting to 'openvpn'
2026-02-21 15:52:31.681854 [info] VPN_PROV defined as 'custom'
2026-02-21 15:52:31.744715 [crit] No OpenVPN config file located in /config/openvpn/ (ovpn extension), please download from your VPN provider and then restart this container.

It also created a new ./openvpn directory. I tried dropping the .conf file in the ./openvpn directory, but it wasn't particularly fond of that and still wouldn't start.

What is the proper string to put in the VPN_CLIENT variable to tell it to use wireguard?

Also, can I use my .conf file as is, do I need to modify it in some way, or simply change it to be a .wg0 file and all is good?

This is what the .conf file contains (sanitized for security):

[Interface]
# Key for UrDeluge
# Bouncing = 2
# NetShield = 0
# Moderate NAT = on
# NAT-PMP (Port Forwarding) = on
# VPN Accelerator = on
PrivateKey = <snip>
Address = 10.2.0.2/32
DNS = 10.2.0.1

[Peer]
# US-GA#321
PublicKey = <snip>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = x.x.x.x:port

PersistentKeepalive = 25

On 1/22/2026 at 10:01 AM, strike said:

Run this instead:

curl ifconfig.io

Funny, with this change that I'm being forced to make, I won't need to, but I appreciate it!

9 hours ago, Free Man said:

What is the proper string to put in the VPN_CLIENT variable to tell it to use wireguard?

Also, can I use my .conf file as is, do I need to modify it in some way, or simply change it to be a .wg0 file and all is good?

Simply put: wireguard

And I'm not sure, but I believe you have to rename it to wg0.conf

And here is the rest of the documentation:

WireGuard

If you wish to use WireGuard (defined via 'VPN_CLIENT' env var value ) then due to the enhanced security and kernel integration WireGuard will require the container to be defined with privileged permissions and sysctl support, so please ensure you change the following docker options:-

from

    --cap-add=NET_ADMIN \

to

    --sysctl="net.ipv4.conf.all.src_valid_mark=1" \
    --privileged=true \

PIA users - The WireGuard configuration file will be auto generated and will be stored in /config/wireguard/wg0.conf AFTER the first run, if you wish to change the endpoint you are connecting to then change the Endpoint line in the config file (default is Netherlands).

Other users - Please download your WireGuard configuration file from your VPN provider, start and stop the container to generate the folder /config/wireguard/ and then place your WireGuard configuration file in there.