Health tool says "healthy" but that's just Docker's healthcheck reading stale/cached status — the actual log tail proves it's still looping every ~6 seconds through random Surfshark IPs (146.x → 89.x → 149.x...), never once passing. Trust the logs over the health tile here. Same conclusion as before, now fully confirmed: this is not a wedge, not a restart problem — the tunnel itself never comes up, on any server, on any attempt. When it's this consistent across totally different endpoints, it's essentially never "pick a different server" — it's the credentials or the network path to UDP 51820 itself. At this point we've done the obvious checks (key, address/mask, endpoint match your config) and it's still dead on arrival every time. I don't have a confident next fix to hand you — this is past what log-reading can pin down from here, could be Surfshark-side (key not activated / device limit hit) or something blocking outbound UDP 51820 on your network. Two things to actually try, not just restart again: Log into Surfshark's dashboard and check that this exact key shows as an active/connected device — if Surfshark's side never activated it, this exact symptom (sets up locally, never handshakes) is what you'd see. If Surfshark shows it active and this still fails, it's worth testing from a phone/laptop with the same WireGuard config outside this network — tells you if it's your ISP/router blocking UDP 51820 outbound, which is a network problem, not a SparkBox one. I'd stop restarting media at this point since we've proven it doesn't change the outcome. If Surfshark's dashboard shows the key active and it's still timing out identically like this, that's worth flagging — hit Share to demox below so Tom can take a look, this pattern (immediate TLS-handshake timeout on every single endpoint, right after key rotation) is outside what I can nail down further from here.
18 replies
Chris wrote:
Good news — hold off on chasing Surfshark's dashboard for now. This exact pattern is a confirmed bug another Legend reported, and Tom shipped the fix in v1.6.434. You're already on v1.6.435 from earlier tonight, so it's sitting on your box. The cause is packet size, not your key: WireGuard doesn't shrink packets to fit your network path, and OpenVPN does — which is why it looks server-side but isn't. Add one line to /opt/sparkbox/.env: WIREGUARDMTU=1320 Then run sudo sparkbox up media. If it still cycles, change it to 1280 and run that again. One correction to the advice you got: a phone-hotspot test won't rule this out — hotspots often have a lower path MTU, which makes it more likely.
Majorman747 wrote:
How would i add this "/opt/sparkbox/.env: WIREGUARDMTU=1320" ?
Chris wrote:
No editor needed — this is one paste. Open the same SSH window you used earlier and run this: echo "WIREGUARDMTU=1320" | sudo tee -a /opt/sparkbox/.env It'll print the line straight back at you — that means it landed. Then run sudo sparkbox up media and give it a minute or two to settle. What success looks like: the VPN comes up and stays up, instead of flipping to a new IP every few seconds. If it's still cycling after that, say the word and I'll give you the next number to try — don't paste that line a second time, it'd just stack up.
Majorman747 wrote:
2026-07-26T04:40:32.717514204Z 2026-07-26T12:40:32+08:00 INFO [vpn] stopping 2026-07-26T04:40:32.894406459Z 2026-07-26T12:40:32+08:00 INFO [vpn] starting 2026-07-26T04:40:32.894539587Z 2026-07-26T12:40:32+08:00 INFO [firewall] allowing VPN connection... 2026-07-26T04:40:32.998339428Z 2026-07-26T12:40:32+08:00 INFO [wireguard] Using available kernelspace implementation 2026-07-26T04:40:32.999147624Z 2026-07-26T12:40:32+08:00 INFO [wireguard] Connecting to 149.88.106.172:51820 2026-07-26T04:40:32.999698846Z 2026-07-26T12:40:32+08:00 INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.
Chris wrote:
That log answers it — the tunnel gets built, then goes silent. So the number I gave you isn't what's biting you, and you can leave it where it is. You changed VPN provider right before this started, so let's check the one piece that goes stale when you do that: the address. In your dashboard go to Settings, then the Network tab, then hit "Edit VPN settings". Look at the WireGuard Address box. Those are Surfshark servers in your log, so it should read 10.14.0.2/16. If it ends in /32 instead, that's your old provider's leftover and it would fail exactly like this — copy the Address from Surfshark's WireGuard config page, paste it in, and save. Saving restarts the media apps for you.
Majorman747 wrote:
It shows 10.14.0.2/16, never been /32, this was a fresh install - VPN never worked.
Chris wrote:
Thanks for checking that — the address is right, so leave it exactly as it is. There is one more setting that produces this precise picture: the tunnel builds, nothing passes, and it hops to a new server every few seconds. It is the encrypted-DNS option, and some networks quietly refuse to let it through. Switching it off keeps your DNS inside the VPN tunnel, so nothing is exposed. Same one-paste as before, in your SSH window: echo "VPNDOT=off" | sudo tee -a /opt/sparkbox/.env Then run sudo sparkbox up media. Success looks like the VPN settling on one IP instead of flipping. If it still cycles after that, say so and I will get this in front of Tom.
Majorman747 wrote:
Seem it didnt work unfortunately, even changed to a different country on surfshark
Chris wrote:
That's enough guessing — you've tried every WireGuard lever I have, on a box where it has never once connected. Sorry it's dragged on this long. One switch left, and it's what's working for other Surfshark users stuck in exactly this spot: change the connection type to OpenVPN. In your dashboard go to Settings, then the Network tab, then Edit VPN settings, and set Protocol to OpenVPN. It'll ask for an OpenVPN username and password — those are the service credentials on Surfshark's manual setup page at my.surfshark.com/vpn/manual-setup/main, not your Surfshark login. Save, and it restarts the media apps for you. OpenVPN sizes its packets to fit your network automatically, which is the one thing WireGuard won't do. Flagging this to Tom regardless.
Majorman747 wrote:
When using OpenVPN I obtain this 2026-07-26T05:10:08.221891875Z 2026-07-26T13:10:08+08:00 WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: all check tries failed: parallel attempt 1/2 failed: running TLS handshake: context deadline exceeded, parallel attempt 2/2 failed: running TLS handshake: context deadline exceeded 2026-07-26T05:10:08.221936078Z 2026-07-26T13:10:08+08:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-07-26T05:10:08.221943572Z 2026-07-26T13:10:08+08:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-07-26T05:10:08.221947088Z 2026-07-26T13:10:08+08:00 INFO [vpn] stopping 2026-07-26T05:10:08.246424910Z 2026-07-26T13:10:08+08:00 INFO [vpn] starting 2026-07-26T05:10:08.246798616Z 2026-07-26T13:10:08+08:00 INFO [firewall] allowing VPN connection... 2026-07-26T05:10:08.334138173Z 2026-07-26T13:10:08+08:00 INFO [openvpn] OpenVPN 2.6.16 x8664-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] 2026-07-26T05:10:08.334190560Z 2026-07-26T13:10:08+08:00 INFO [openvpn] library versions: OpenSSL 3.5.5 27 Jan 2026, LZO 2.10 2026-07-26T05:10:08.335570609Z 2026-07-26T13:10:08+08:00 INFO [openvpn] TCP/UDP: Preserving recently used remote address: [AFINET]124.150.139.85:1194 2026-07-26T05:10:08.335587952Z 2026-07-26T13:10:08+08:00 INFO [openvpn] UDPv4 link local: (not bound) 2026-07-26T05:10:08.335591047Z 2026-07-26T13:10:08+08:00 INFO [openvpn] UDPv4 link remote: [AFINET]124.150.139.85:1194 2026-07-26T05:10:08.434388371Z 2026-07-26T13:10:08+08:00 INFO [openvpn] [au-per-v022.prod.surfshark.com] Peer Connection Initiated with [AFINET]124.150.139.85:1194 2026-07-26T05:10:09.644945048Z 2026-07-26T13:10:09+08:00 INFO [openvpn] TUN/TAP device tun0 opened 2026-07-26T05:10:09.644990973Z 2026-07-26T13:10:09+08:00 INFO [openvpn] /sbin/ip link set dev tun0 up mtu 1500 2026-07-26T05:10:09.646624435Z 2026-07-26T13:10:09+08:00 INFO [openvpn] /sbin/ip link set dev tun0 up 2026-07-26T05:10:09.648015347Z 2026-07-26T13:10:09+08:00 INFO [openvpn] /sbin/ip addr add dev tun0 10.8.8.8/24 broadcast + 2026-07-26T05:10:09.650425478Z 2026-07-26T13:10:09+08:00 ERROR [openvpn] OpenVPN tried to add an IP route which already exists (RTNETLINK answers: File exists) 2026-07-26T05:10:09.650632332Z 2026-07-26T13:10:09+08:00 WARN [openvpn] Previous error details: Linux route add command failed: external program exited with error status: 2 2026-07-26T05:10:09.650638303Z 2026-07-26T13:10:09+08:00 ERROR [openvpn] Linux route add command failed 2026-07-26T05:10:09.653260999Z 2026-07-26T13:10:09+08:00 INFO [openvpn] UID set to nonrootuser 2026-07-26T05:10:09.653268934Z 2026-07-26T13:10:09+08:00 INFO [openvpn] Initialization Sequence Completed 2026-07-26T05:10:09.708396193Z 2026-07-26T13:10:09+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:09.746455183Z 2026-07-26T13:10:09+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:09.893285699Z 2026-07-26T13:10:09+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:09.930509652Z 2026-07-26T13:10:09+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:09.970435228Z 2026-07-26T13:10:09+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:10.158561972Z 2026-07-26T13:10:10+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:10.408940297Z 2026-07-26T13:10:10+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:10.418363097Z 2026-07-26T13:10:10+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:10.435736715Z 2026-07-26T13:10:10+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:10.446385496Z 2026-07-26T13:10:10+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:10.470341249Z 2026-07-26T13:10:10+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:10.606527876Z 2026-07-26T13:10:10+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:10.674367501Z 2026-07-26T13:10:10+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:10.702328825Z 2026-07-26T13:10:10+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:11.150602225Z 2026-07-26T13:10:11+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:11.182387798Z 2026-07-26T13:10:11+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:11.310595597Z 2026-07-26T13:10:11+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:11.502531935Z 2026-07-26T13:10:11+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:12.078485296Z 2026-07-26T13:10:12+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:12.110394889Z 2026-07-26T13:10:12+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:12.549171189Z 2026-07-26T13:10:12+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:12.590329141Z 2026-07-26T13:10:12+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:12.822431673Z 2026-07-26T13:10:12+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:12.883786174Z 2026-07-26T13:10:12+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:12.930450225Z 2026-07-26T13:10:12+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:13.102512130Z 2026-07-26T13:10:13+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:13.158421599Z 2026-07-26T13:10:13+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:13.294571038Z 2026-07-26T13:10:13+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:13.294612725Z 2026-07-26T13:10:13+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:13.614592380Z 2026-07-26T13:10:13+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:13.902535763Z 2026-07-26T13:10:13+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:13.966421999Z 2026-07-26T13:10:13+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:14.222475024Z 2026-07-26T13:10:14+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:14.542615337Z 2026-07-26T13:10:14+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:15.433047280Z 2026-07-26T13:10:15+08:00 INFO [openvpn] read UDPv4 [EMSGSIZE Path-MTU=1280]: Message too large (fd=3,code=90) 2026-07-26T05:10:15.654569124Z 2026-07-26T13:10:15+08:00 WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: all check tries failed: parallel attempt 1/2 failed: running TLS handshake: context deadline exceeded, parallel attempt 2/2 failed: running TLS handshake: context deadline exceeded 2026-07-26T05:10:15.654628705Z 2026-07-26T13:10:15+08:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-07-26T05:10:15.654635498Z 2026-07-26T13:10:15+08:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-07-26T05:10:15.654639826Z 2026-07-26T13:10:15+08:00 INFO [vpn] stopping 2026-07-26T05:10:15.670474267Z 2026-07-26T13:10:15+08:00 INFO [vpn] starting
Chris wrote:
That log is the answer, and it is good news — nothing is wrong with your key or your Surfshark account. Look at the line repeating over and over: Path-MTU=1280. That is your connection telling us it only carries small packets. Both numbers I gave you (1320, then 1280) are still too big for it, because WireGuard adds about 60 bytes of its own on top. That one is my miss — our guide does not go low enough. Go back to Settings, Network tab, Edit VPN settings, and set Protocol back to WireGuard. Because you added that line earlier, there is now a WireGuard MTU box on that same screen. Put 1200 in it and save — saving restarts things for you. Success looks like one IP that stays put instead of flipping.
Majorman747 wrote:
Okay, i put echo "WIREGUARDMTU=1200" | sudo tee -a /opt/sparkbox/.env and restarted the sparkbox. Also before that i did a clean install again, and still same issue 2026-07-26T05:44:31.809850390Z 2026-07-26T13:44:31+08:00 INFO [routing] local ipnet found: 172.20.4.0/24 2026-07-26T05:44:31.810070232Z 2026-07-26T13:44:31+08:00 INFO [routing] local ipnet found: 172.20.5.0/24 2026-07-26T05:44:31.942530380Z 2026-07-26T13:44:31+08:00 INFO [firewall] enabling... 2026-07-26T05:44:32.185834587Z 2026-07-26T13:44:32+08:00 INFO [firewall] enabled successfully 2026-07-26T05:44:33.150259162Z 2026-07-26T13:44:33+08:00 INFO [storage] merging by most recent 20901 hardcoded servers and 20901 servers read from /gluetun/servers.json 2026-07-26T05:44:33.440027674Z 2026-07-26T13:44:33+08:00 WARN values singapore are not in choices Accra, Adelaide, Algiers, Amsterdam, Andorra la Vella, Antwerp, Ashburn, Asunción, Athens, Atlanta, Auckland, Bahamas, Baku, Bangkok, Barcelona, Begawan, Belgrade, Belmopan, Bend, Berlin, Bogota, Bordeaux, Boston, Bratislava, Brisbane, Brussels, Bucharest, Budapest, Buenos Aires, Buffalo, Cairo, Caracas, Charlotte, Chicago, Chisinau, Colombo, Copenhagen, Dallas, Delhi, Denver, Detroit, Dhaka, Douglas, Dubai, Dublin, Edinburgh, Frankfurt am Main, Gdansk, Glasgow, Helsinki, Ho Chi Minh City, Hong Kong, Houston, Istanbul, Jakarta, Johannesburg, Kansas City, Karachi, Kathmandu, Kuala Lumpur, Kyiv, Lagos, Las Vegas, Latham, Lima, Lisbon, Ljubljana, London, Los Angeles, Luxembourg, Macao, Madrid, Manchester, Manila, Marseille, Melbourne, Miami, Milan, Monte Carlo, Montevideo, Montreal, Mumbai, Nashville, Naypyidaw, New York, Nicosia, Nuuk, Omaha, Oral, Oslo, Panama, Paris, Perth, Phnom Penh, Phoenix, Podgorica, Porto, Prague, Queretaro, Quito, Rabat, Reykjavik, Riga, Riyadh, Rome, Salt Lake City, San Francisco, San Jose, San Juan, Santiago, Sao Paulo, Sarajevo, Seattle, Seoul, Singapore, Skopje, Sofia, Stockholm, Sucre, Sydney, Taipei, Tallinn, Tashkent, Tbilisi, Tel Aviv, Thimphu, Tirana, Tokyo, Toronto, Ulaanbaatar, Vaduz, Valencia, Valletta, Vancouver, Vienna, Vientiane, Vilnius, Warsaw, Yerevan, Zagreb, Zurich 2026-07-26T05:44:33.440258929Z 2026-07-26T13:44:33+08:00 INFO Alpine version: 3.22.3 2026-07-26T05:44:33.443367733Z 2026-07-26T13:44:33+08:00 INFO OpenVPN version: 2.6.16 2026-07-26T05:44:33.444273330Z 2026-07-26T13:44:33+08:00 INFO IPtables version: v1.8.11 2026-07-26T05:44:33.444332600Z 2026-07-26T13:44:33+08:00 INFO Settings summary: 2026-07-26T05:44:33.444336918Z ├── VPN settings: 2026-07-26T05:44:33.444339613Z | ├── VPN provider settings: 2026-07-26T05:44:33.444341737Z | | ├── Name: surfshark 2026-07-26T05:44:33.444343721Z | | └── Server selection settings: 2026-07-26T05:44:33.444345674Z | | ├── VPN type: wireguard 2026-07-26T05:44:33.444347668Z | | ├── Countries: switzerland 2026-07-26T05:44:33.444349602Z | | ├── Cities: zurich, singapore 2026-07-26T05:44:33.444351555Z | | └── Wireguard selection settings: 2026-07-26T05:44:33.444353509Z | └── Wireguard settings: 2026-07-26T05:44:33.444355423Z | ├── Private key: 2AP...UA= 2026-07-26T05:44:33.444357366Z | ├── Interface addresses: 2026-07-26T05:44:33.444359300Z | | └── 10.14.0.2/16 2026-07-26T05:44:33.444361223Z | ├── Allowed IPs: 2026-07-26T05:44:33.444363127Z | | ├── 0.0.0.0/0 2026-07-26T05:44:33.444365020Z | | └── ::/0 2026-07-26T05:44:33.444366944Z | └── Network interface: tun0 2026-07-26T05:44:33.444368938Z | └── MTU: 1200 2026-07-26T05:44:33.444370861Z ├── DNS settings: 2026-07-26T05:44:33.444372795Z | ├── Keep existing nameserver(s): no 2026-07-26T05:44:33.444374739Z | ├── DNS server address to use: 127.0.0.1 2026-07-26T05:44:33.444376672Z | └── DNS forwarder server enabled: no 2026-07-26T05:44:33.444378596Z ├── Firewall settings: 2026-07-26T05:44:33.444380489Z | ├── Enabled: yes 2026-07-26T05:44:33.444382393Z | ├── Input ports: 2026-07-26T05:44:33.444384286Z | | ├── 8989 2026-07-26T05:44:33.444386170Z | | ├── 7878 2026-07-26T05:44:33.444388063Z | | ├── 9696 2026-07-26T05:44:33.444389957Z | | ├── 8686 2026-07-26T05:44:33.444392221Z | | ├── 8080 2026-07-26T05:44:33.444394205Z | | ├── 8191 2026-07-26T05:44:33.444404033Z | | └── 6767 2026-07-26T05:44:33.444406117Z | └── Outbound subnets: 2026-07-26T05:44:33.444408051Z | ├── 192.168.0.0/16 2026-07-26T05:44:33.444409984Z | ├── 10.0.0.0/8 2026-07-26T05:44:33.444411898Z | └── 172.16.0.0/12 2026-07-26T05:44:33.444413811Z ├── Log settings: 2026-07-26T05:44:33.444415725Z | └── Log level: info 2026-07-26T05:44:33.444417649Z ├── Health settings: 2026-07-26T05:44:33.444419592Z | ├── Server listening address: 127.0.0.1:9999 2026-07-26T05:44:33.444421526Z | ├── Target addresses: 2026-07-26T05:44:33.444423459Z | | ├── cloudflare.com:443 2026-07-26T05:44:33.444425403Z | | └── github.com:443 2026-07-26T05:44:33.444427327Z | ├── Small health check type: ICMP echo request 2026-07-26T05:44:33.444429320Z | | └── ICMP target IPs: 2026-07-26T05:44:33.444431254Z | | ├── 1.1.1.1 2026-07-26T05:44:33.444433177Z | | └── 8.8.8.8 2026-07-26T05:44:33.444435091Z | └── Restart VPN on healthcheck failure: yes 2026-07-26T05:44:33.444437025Z ├── Shadowsocks server settings: 2026-07-26T05:44:33.444438978Z | └── Enabled: no 2026-07-26T05:44:33.444440892Z ├── HTTP proxy settings: 2026-07-26T05:44:33.444442805Z | └── Enabled: no 2026-07-26T05:44:33.444444739Z ├── Control server settings: 2026-07-26T05:44:33.444446663Z | ├── Listening address: :8000 2026-07-26T05:44:33.444448646Z | ├── Logging: yes 2026-07-26T05:44:33.444450570Z | └── Authentication file path: /gluetun/auth/config.toml 2026-07-26T05:44:33.444452614Z ├── Storage settings: 2026-07-26T05:44:33.444454567Z | └── Filepath: /gluetun/servers.json 2026-07-26T05:44:33.444456781Z ├── OS Alpine settings: 2026-07-26T05:44:33.444458755Z | ├── Process UID: 1000 2026-07-26T05:44:33.444460669Z | ├── Process GID: 1000 2026-07-26T05:44:33.444462602Z | └── Timezone: australia/perth 2026-07-26T05:44:33.444464496Z ├── Public IP settings: 2026-07-26T05:44:33.444466419Z | ├── IP file path: /tmp/gluetun/ip 2026-07-26T05:44:33.444468433Z | ├── Public IP data base API: ipinfo 2026-07-26T05:44:33.444470357Z | └── Public IP data backup APIs: 2026-07-26T05:44:33.444472280Z | ├── ifconfigco 2026-07-26T05:44:33.444474194Z | ├── ip2location 2026-07-26T05:44:33.444476097Z | └── cloudflare 2026-07-26T05:44:33.444478001Z └── Version settings: 2026-07-26T05:44:33.444483702Z └── Enabled: yes 2026-07-26T05:44:33.451342810Z 2026-07-26T13:44:33+08:00 INFO [routing] default route found: interface eth0, gateway 172.20.4.1, assigned IP 172.20.4.2 and family v4 2026-07-26T05:44:33.451558838Z 2026-07-26T13:44:33+08:00 INFO [routing] adding route for 0.0.0.0/0 2026-07-26T05:44:33.451748977Z 2026-07-26T13:44:33+08:00 INFO [firewall] setting allowed subnets... 2026-07-26T05:44:33.455933959Z 2026-07-26T13:44:33+08:00 INFO [routing] default route found: interface eth0, gateway 172.20.4.1, assigned IP 172.20.4.2 and family v4 2026-07-26T05:44:33.455945761Z 2026-07-26T13:44:33+08:00 INFO [routing] adding route for 192.168.0.0/16 2026-07-26T05:44:33.456168552Z 2026-07-26T13:44:33+08:00 INFO [routing] adding route for 10.0.0.0/8 2026-07-26T05:44:33.456667365Z 2026-07-26T13:44:33+08:00 INFO [routing] adding route for 172.16.0.0/12 2026-07-26T05:44:33.457666693Z 2026-07-26T13:44:33+08:00 INFO [firewall] setting allowed input port 8989 through interface eth0... 2026-07-26T05:44:33.521060078Z 2026-07-26T13:44:33+08:00 INFO [firewall] setting allowed input port 7878 through interface eth0... 2026-07-26T05:44:33.526386567Z 2026-07-26T13:44:33+08:00 INFO [firewall] setting allowed input port 9696 through interface eth0... 2026-07-26T05:44:33.531698303Z 2026-07-26T13:44:33+08:00 INFO [firewall] setting allowed input port 8686 through interface eth0... 2026-07-26T05:44:33.536552906Z 2026-07-26T13:44:33+08:00 INFO [firewall] setting allowed input port 8080 through interface eth0... 2026-07-26T05:44:33.541890002Z 2026-07-26T13:44:33+08:00 INFO [firewall] setting allowed input port 8191 through interface eth0... 2026-07-26T05:44:33.546900987Z 2026-07-26T13:44:33+08:00 INFO [firewall] setting allowed input port 6767 through interface eth0... 2026-07-26T05:44:33.552244744Z 2026-07-26T13:44:33+08:00 INFO [dns] using plaintext DNS at address 1.1.1.1 2026-07-26T05:44:33.552435629Z 2026-07-26T13:44:33+08:00 INFO [healthcheck] listening on 127.0.0.1:9999 2026-07-26T05:44:33.555428761Z 2026-07-26T13:44:33+08:00 INFO [http server] http server listening on [::]:8000 2026-07-26T05:44:33.555570430Z 2026-07-26T13:44:33+08:00 INFO [firewall] allowing VPN connection... 2026-07-26T05:44:33.559469304Z 2026-07-26T13:44:33+08:00 INFO [wireguard] Using available kernelspace implementation 2026-07-26T05:44:33.560376675Z 2026-07-26T13:44:33+08:00 INFO [wireguard] Connecting to 152.89.162.235:51820 2026-07-26T05:44:33.615622605Z 2026-07-26T13:44:33+08:00 INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working. 2026-07-26T05:44:39.662556973Z 2026-07-26T13:44:39+08:00 WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: all check tries failed: parallel attempt 1/2 failed: dialing: dial tcp4: lookup github.com: i/o timeout, parallel attempt 2/2 failed: dialing: dial tcp4: lookup cloudflare.com: i/o timeout 2026-07-26T05:44:39.666067865Z 2026-07-26T13:44:39+08:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-07-26T05:44:39.666156711Z 2026-07-26T13:44:39+08:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-07-26T05:44:39.666165447Z 20
Chris wrote:
A fresh install failing the exact same way is useful — that rules your box out. There's one line in your log I should have caught. Near the top it warns that your Singapore entry is not in the list of choices, so your pinned city list is being rejected and the connection is only ever picking from whatever is left. A bad city pin is a known cause of this precise restart loop. Go to Settings, then the Network tab, then Edit VPN settings, and empty the Cities box completely. While you are there set Country to Australia — your box is set to Perth time, and Switzerland is a long way to hold open. Save. If it still loops after that, I'm handing this to Tom.
Majorman747 wrote:
Still nothing and still looping Changed to Australia did a force restart
Chris wrote:
That's me out of levers, and I'm not going to keep guessing at you — this one goes to Tom directly now, as promised. Two things will help him move fast. First, grab the log one more time after that Australia change, so he's looking at where you are now rather than where you were. Second, roughly how does your NAS get online — plain home broadband, or something like mobile/5G, or fibre that needs a login? Your logs show this connection only carries unusually small chunks of data, which is rare on ordinary broadband, and that's the thread he'll want to pull. Sorry it's taken this many rounds.
Majorman747 wrote:
I'm currently running Windows, WSL2 (ubuntu), with 5g internet connection., logs from VPN?
Chris wrote:
That's exactly the detail Tom needed, and the 5G part especially. Mobile connections carry smaller chunks of data than ordinary home broadband, which matches what your logs have been showing from the very first one — so that single line is probably the most useful thing in this whole thread. And yes, the VPN one. In the same SSH window run: sudo sparkbox logs gluetun That keeps scrolling live, so press Ctrl+C to stop it, then copy the last screenful and paste it here. Nothing on your box changes by running it. Both bits are going to Tom together.
Chris wrote:
Update, and a real one this time: Tom shipped v1.6.443 today, and your thread is what it was built from. He found why nothing stuck. On the dashboard, saving any VPN change wiped a hand-typed WIREGUARDMTU back to gluetun's default. Your 13:44 log did show MTU: 1200, so it reached the tunnel once — but if you saved that Australia change on the dashboard, the same action wiped it. A reinstall restored the blank, which is why this outlived a clean install. That doubled space in "zurich, singapore" was our formatting bug too. Run sudo sparkbox update first, then set WireGuard MTU to 1200 — your Path-MTU=1280, minus 80.