[GH-ISSUE #5955] NetBird Cloud Reverse Proxy 502 Destination Unreachable Error #11946

New Issue

Originally created by @mga1981 on GitHub (Apr 21, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5955

Describe the problem

NetBird Cloud reverse proxy returns HTTP 502 "Destination Unreachable" error when accessing internal services through custom domains, despite successful authentication and verified backend connectivity. The proxy authenticates users correctly (PIN works), then fails to connect to the destination after a 2-3 minute delay. Both tested services fail identically. The same backend services work perfectly when exposed via Cloudflare Tunnel, ruling out network/firewall issues.

To Reproduce

Steps to reproduce the behavior:

Go to NetBird Cloud dashboard > Reverse Proxy > Services
Create HTTPS service with custom domain (e.g., service.myserver.com)
Configure target as network resource (10.x.x.x/24) pointing to http://10.x.x.200:8081
Add PIN authentication
Access the domain from browser
Enter PIN when prompted
Wait for authentication to complete (shows "Authenticated")
See HTTP 502 error after 2-3 minute spinning delay with status "Destination Unreachable"

Expected behavior

Reverse proxy should forward authenticated requests to the backend service at http://10.0.0.166:8081 and return the service response, not a 502 error.

Are you using NetBird Cloud?

Yes, NetBird Cloud (free tier).

NetBird version

Daemon version: 0.69.0
CLI version: 0.69.0

Is any other VPN software installed?

No. Only NetBird is running as VPN software. Cloudflare Tunnel is used for comparison testing only (not active simultaneously).

Debug output

NetBird status output:
OS: linux/amd64
Daemon version: 0.69.0
CLI version: 0.69.0
Profile: default
Management: Connected
Signal: Connected
Relays: 4/4 Available
Nameservers: 0/0 Available
FQDN: mgaug-17-21.netbird.cloud
NetBird IP: 10.x.x.x/16
Interface type: Kernel
Quantum resistance: false
Lazy connection: false
SSH Server: Disabled
Networks: 10.x.x.x/24
Peers count: 2/3 Connected

Screenshots

Service configuration showing:

Domain: service.myserver.com
Service Type: HTTPS Service
Cluster: eu1.netbird.services
Resource: home network (10.x.x.x/24)
Destination: http://10.x.x.200:8081
Status: Active
Result: "Connection Error - Destination Unreachable"

Additional context

What Works:

Direct HTTP access to http://10.x.x.200:8081
Same service via Cloudflare Tunnel at same domain
iPhone on 5G (via NetBird VPN) can ping 10.x.x.200 (0% packet loss)
TCP port 8081 is open and reachable
PIN authentication succeeds before 502 error
NetBird peer connectivity is functional (Management/Signal/Relays all connected)

Configuration Details:

Custom domain: myserver.com (CNAME verified in Cloudflare)
Network resource: home network (10.x.x.x/24)
Two services tested: service.myserver.com → http://10.x.x.200:8081 and service2.myserver.com → http://10.x.x.201:7878
Both fail with identical error
No access control rules configured
Advanced settings: Pass Host Header disabled, Rewrite Redirects disabled

Comparison with Cloudflare Tunnel:
The exact same backend service (http://10.x.x.200:8081) is accessible without issues via Cloudflare Tunnel at the same domain (service.myserver.com), confirming the backend is reachable and the issue is specific to NetBird reverse proxy.

Have you tried these troubleshooting steps?

Reviewed client troubleshooting (if applicable)
Checked for newer NetBird versions (running 0.69.0)
Searched for similar issues on GitHub (found #5684, #5571, #5485 - none resolved)
Restarted the NetBird client
Disabled other VPN software (only tested with Cloudflare Tunnel for comparison)
Checked firewall settings (no blocking rules on NAS)
Verified TCP connectivity from NetBird container to backend ports
Tested multiple backend services on different ports (same error)
Verified network resource configuration is correct
Confirmed direct backend access works

Originally created by @mga1981 on GitHub (Apr 21, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5955 **Describe the problem** NetBird Cloud reverse proxy returns HTTP 502 "Destination Unreachable" error when accessing internal services through custom domains, despite successful authentication and verified backend connectivity. The proxy authenticates users correctly (PIN works), then fails to connect to the destination after a 2-3 minute delay. Both tested services fail identically. The same backend services work perfectly when exposed via Cloudflare Tunnel, ruling out network/firewall issues. **To Reproduce** Steps to reproduce the behavior: 1. Go to NetBird Cloud dashboard > Reverse Proxy > Services 2. Create HTTPS service with custom domain (e.g., service.myserver.com) 3. Configure target as network resource (10.x.x.x/24) pointing to http://10.x.x.200:8081 4. Add PIN authentication 5. Access the domain from browser 6. Enter PIN when prompted 7. Wait for authentication to complete (shows "Authenticated") 8. See HTTP 502 error after 2-3 minute spinning delay with status "Destination Unreachable" **Expected behavior** Reverse proxy should forward authenticated requests to the backend service at http://10.0.0.166:8081 and return the service response, not a 502 error. **Are you using NetBird Cloud?** Yes, NetBird Cloud (free tier). **NetBird version** Daemon version: 0.69.0 CLI version: 0.69.0 **Is any other VPN software installed?** No. Only NetBird is running as VPN software. Cloudflare Tunnel is used for comparison testing only (not active simultaneously). **Debug output** NetBird status output: OS: linux/amd64 Daemon version: 0.69.0 CLI version: 0.69.0 Profile: default Management: Connected Signal: Connected Relays: 4/4 Available Nameservers: 0/0 Available FQDN: mgaug-17-21.netbird.cloud NetBird IP: 10.x.x.x/16 Interface type: Kernel Quantum resistance: false Lazy connection: false SSH Server: Disabled Networks: 10.x.x.x/24 Peers count: 2/3 Connected **Screenshots** Service configuration showing: - Domain: service.myserver.com - Service Type: HTTPS Service - Cluster: eu1.netbird.services - Resource: home network (10.x.x.x/24) - Destination: http://10.x.x.200:8081 - Status: Active - Result: "Connection Error - Destination Unreachable" **Additional context** What Works: - Direct HTTP access to http://10.x.x.200:8081 - Same service via Cloudflare Tunnel at same domain - iPhone on 5G (via NetBird VPN) can ping 10.x.x.200 (0% packet loss) - TCP port 8081 is open and reachable - PIN authentication succeeds before 502 error - NetBird peer connectivity is functional (Management/Signal/Relays all connected) Configuration Details: - Custom domain: myserver.com (CNAME verified in Cloudflare) - Network resource: home network (10.x.x.x/24) - Two services tested: service.myserver.com → http://10.x.x.200:8081 and service2.myserver.com → http://10.x.x.201:7878 - Both fail with identical error - No access control rules configured - Advanced settings: Pass Host Header disabled, Rewrite Redirects disabled Comparison with Cloudflare Tunnel: The exact same backend service (http://10.x.x.200:8081) is accessible without issues via Cloudflare Tunnel at the same domain (service.myserver.com), confirming the backend is reachable and the issue is specific to NetBird reverse proxy. **Have you tried these troubleshooting steps?** - [x] Reviewed client troubleshooting (if applicable) - [x] Checked for newer NetBird versions (running 0.69.0) - [x] Searched for similar issues on GitHub (found #5684, #5571, #5485 - none resolved) - [x] Restarted the NetBird client - [x] Disabled other VPN software (only tested with Cloudflare Tunnel for comparison) - [x] Checked firewall settings (no blocking rules on NAS) - [x] Verified TCP connectivity from NetBird container to backend ports - [x] Tested multiple backend services on different ports (same error) - [x] Verified network resource configuration is correct - [x] Confirmed direct backend access works

saavagebueno added the triage-needed label 2026-08-05 01:31:49 -04:00

saavagebueno commented

@SamThingElse commented on GitHub (Apr 22, 2026):

I have a similar problem. The difference in my setup, however, is that it works at first, but after a while (usually when there haven't been any requests for a while), the problem described occurs. Based on my logs and testing, this looks less like a connectivity issue and more like an internal proxy/tunnel state problem.

Looking at the logs, I repeatedly see messages like "httputil: ReverseProxy read error during body copy: unexpected EOF" and "ICE Agent is not initialized yet". From my (admittedly limited) understanding, this suggests that the proxy is able to accept and authenticate the request, but fails when trying to establish or reuse the underlying connection to the target via ICE. The fact that this also tends to happen after periods of inactivity makes me suspect some kind of stale or broken internal connection state that isn’t properly re-initialized.

As a temporary workaround for me, restarting the "netbird-proxy" container immediately resolves the issue and everything works again afterwards. I’m not sure if this would help in your case, as it seems it never worked for you from the start.

That said, these are just observations and best-effort conclusions from my side. This workaround is definitely not ideal.

@SamThingElse commented on GitHub (Apr 22, 2026): I have a similar problem. The difference in my setup, however, is that it works at first, but after a while (usually when there haven't been any requests for a while), the problem described occurs. Based on my logs and testing, this looks less like a connectivity issue and more like an internal proxy/tunnel state problem. Looking at the logs, I repeatedly see messages like "httputil: ReverseProxy read error during body copy: unexpected EOF" and "ICE Agent is not initialized yet". From my (admittedly limited) understanding, this suggests that the proxy is able to accept and authenticate the request, but fails when trying to establish or reuse the underlying connection to the target via ICE. The fact that this also tends to happen after periods of inactivity makes me suspect some kind of stale or broken internal connection state that isn’t properly re-initialized. As a temporary workaround for me, restarting the "netbird-proxy" container immediately resolves the issue and everything works again afterwards. I’m not sure if this would help in your case, as it seems it never worked for you from the start. That said, these are just observations and best-effort conclusions from my side. This workaround is definitely not ideal.

saavagebueno commented

@njayasathya commented on GitHub (Apr 26, 2026):

Facing the same issue. I think the issue is when we hit the URL in the browser, there are 2 IP addresses returned indicating that the site has 2 proxies. But when checked in the NetBird peer status, only 1 proxy is connected. So whenever the 2nd IP address (which is not connected in the peer) is hit, we get the 502 error.

A few days back I saw 2 proxy connections in my peer, but today I only see only 1.

root@<redacted-host>:~# netbird status -d
Peers detail:
 proxy-<redacted>.netbird.cloud:
  NetBird IP: <redacted>
  Public key: <redacted>
  Status: Connected
  -- detail --
  Connection type: Relayed
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address: rels://<redacted>.relay.netbird.io:443
  Last connection update: <redacted>
  Last WireGuard handshake: <redacted>
  Transfer status (received/sent) <redacted>
  Quantum resistance: false
  Networks: -
  Latency: <redacted>

Events:
  [INFO] SYSTEM (<redacted>)
    Message: Network map updated
    Time: <redacted>
  [INFO] SYSTEM (<redacted>)
    Message: Network map updated
    Time: <redacted>

OS: linux/amd64
Daemon version: <redacted>
CLI version: <redacted>
Profile: default
Management: Connected to https://api.netbird.io:443
Signal: Connected to https://signal.netbird.io:443
Relays:
  [stun:stun.netbird.io:443] is Available
  [stun:stun.netbird.io:5555] is Available
  [turns:turn.netbird.io:443?transport=tcp] is Available
  [rels://<redacted>.relay.netbird.io:443] is Available

Nameservers:
FQDN: <redacted>
NetBird IP: <redacted>
Interface type: Kernel
Quantum resistance: false
Lazy connection: false
SSH Server: Disabled
Networks: <redacted>
Peers count: 1/1 Connected
root@<redacted-host>:~#

C:\Users\<redacted>>curl -vk https://<redacted-domain>/
* Host <redacted-domain>:443 was resolved.
* IPv6: (none)
* IPv4: <redacted>, <redacted>
*   Trying <redacted>:443...
* schannel: disabled automatic use of client certificate

@njayasathya commented on GitHub (Apr 26, 2026): Facing the same issue. I think the issue is when we hit the URL in the browser, there are 2 IP addresses returned indicating that the site has 2 proxies. But when checked in the NetBird peer status, only 1 proxy is connected. So whenever the 2nd IP address (which is not connected in the peer) is hit, we get the 502 error. A few days back I saw 2 proxy connections in my peer, but today I only see only 1. ``` root@<redacted-host>:~# netbird status -d Peers detail: proxy-<redacted>.netbird.cloud: NetBird IP: <redacted> Public key: <redacted> Status: Connected -- detail -- Connection type: Relayed ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: rels://<redacted>.relay.netbird.io:443 Last connection update: <redacted> Last WireGuard handshake: <redacted> Transfer status (received/sent) <redacted> Quantum resistance: false Networks: - Latency: <redacted> Events: [INFO] SYSTEM (<redacted>) Message: Network map updated Time: <redacted> [INFO] SYSTEM (<redacted>) Message: Network map updated Time: <redacted> OS: linux/amd64 Daemon version: <redacted> CLI version: <redacted> Profile: default Management: Connected to https://api.netbird.io:443 Signal: Connected to https://signal.netbird.io:443 Relays: [stun:stun.netbird.io:443] is Available [stun:stun.netbird.io:5555] is Available [turns:turn.netbird.io:443?transport=tcp] is Available [rels://<redacted>.relay.netbird.io:443] is Available Nameservers: FQDN: <redacted> NetBird IP: <redacted> Interface type: Kernel Quantum resistance: false Lazy connection: false SSH Server: Disabled Networks: <redacted> Peers count: 1/1 Connected root@<redacted-host>:~# ``` ``` C:\Users\<redacted>>curl -vk https://<redacted-domain>/ * Host <redacted-domain>:443 was resolved. * IPv6: (none) * IPv4: <redacted>, <redacted> * Trying <redacted>:443... * schannel: disabled automatic use of client certificate ```

saavagebueno commented

@erlendwtf commented on GitHub (Apr 26, 2026):

I'm seeing the same "Error 502" from the reverse proxy on my custom domain. The secondary IP resolved for the FQDN of the proxy service seems to be dead.

@erlendwtf commented on GitHub (Apr 26, 2026): I'm seeing the same "Error 502" from the reverse proxy on my custom domain. The secondary IP resolved for the FQDN of the proxy service seems to be dead.

saavagebueno commented

@NDebx commented on GitHub (May 1, 2026):

Having the same issue....

@NDebx commented on GitHub (May 1, 2026): Having the same issue....

saavagebueno commented

@NDebx commented on GitHub (May 1, 2026):

For me only works to recreate the netbird compose file and then it works again but after a few hours idle then everything is down again..

@NDebx commented on GitHub (May 1, 2026): For me only works to recreate the netbird compose file and then it works again but after a few hours idle then everything is down again..

saavagebueno commented

@Bajahaw commented on GitHub (May 1, 2026):

having the same issue, no matter how many times i recreate the routing peer container ... this is where i got so far:

DNS resolution for my.sub.domain.com
→ 57.129.98.79 ← unhealthy proxy node → 502
→ 54.37.79.68 ← healthy proxy node → 200

Root cause: NetBird upstream cluster (eu1.netbird.services)
returns 2 IPs, one with broken tunnel to my network.
DNS round-robin causes intermittent 502s. Due to that, all my services have ~50% uptime now

After Applying hosts file pin to 54.37.79.68 it works consistently, but only from client machine.

I hope it is fixed soon ..

@Bajahaw commented on GitHub (May 1, 2026): having the same issue, no matter how many times i recreate the routing peer container ... this is where i got so far: DNS resolution for my.sub.domain.com → 57.129.98.79 ← unhealthy proxy node → 502 → 54.37.79.68 ← healthy proxy node → 200 Root cause: NetBird upstream cluster (eu1.netbird.services) returns 2 IPs, one with broken tunnel to my network. DNS round-robin causes intermittent 502s. Due to that, all my services have ~50% uptime now After Applying hosts file pin to 54.37.79.68 it works consistently, but only from client machine. I hope it is fixed soon ..

saavagebueno commented

@micromacman commented on GitHub (May 3, 2026):

Having the same issue.

@micromacman commented on GitHub (May 3, 2026): Having the same issue.

saavagebueno commented

@fruchttiger87 commented on GitHub (May 5, 2026):

I have the same issue with three exposed services. They worked for weeks ans since May 1st, i have an uptime less than 50 percent.

@fruchttiger87 commented on GitHub (May 5, 2026): I have the same issue with three exposed services. They worked for weeks ans since May 1st, i have an uptime less than 50 percent.

saavagebueno commented

@NDebx commented on GitHub (May 5, 2026):

I fixed it temporarily by running uptime kuma locally and sending health checks every 60 seconds. With this setup I'm forcing the proxy to be alive.

I don't have any downtime past 5 days. But finger crossed if the issue will be fixed.

@NDebx commented on GitHub (May 5, 2026): I fixed it temporarily by running uptime kuma locally and sending health checks every 60 seconds. With this setup I'm forcing the proxy to be alive. I don't have any downtime past 5 days. But finger crossed if the issue will be fixed.

saavagebueno commented

@sjansen1 commented on GitHub (Jun 8, 2026):

Maybe their cluster is having the same issue i have. I have a proxy cluster containing two nodes. Only one of them works and forwards web traffic to my internal network. If i stop the non working proxy, the client tries the other one and works.

I think only one of the proxy always work and the other always fails, if i redeploy, the order may be different and another proxy does not proxy.

@sjansen1 commented on GitHub (Jun 8, 2026): Maybe their cluster is having the same issue i have. I have a proxy cluster containing two nodes. Only one of them works and forwards web traffic to my internal network. If i stop the non working proxy, the client tries the other one and works. I think only one of the proxy always work and the other always fails, if i redeploy, the order may be different and another proxy does not proxy.

saavagebueno commented

@0qie commented on GitHub (Jul 9, 2026):

today similar issue according to fable the node of netbird side 54.37.79.68 is ded
had to put a record instead of cname to 57.129.98.79 and it worked

@0qie commented on GitHub (Jul 9, 2026): today similar issue according to fable the node of netbird side 54.37.79.68 is ded had to put a record instead of cname to 57.129.98.79 and it worked

saavagebueno commented

@Bajahaw commented on GitHub (Jul 9, 2026):

@0qie me too having the same issue yesterday and today as well.

@Bajahaw commented on GitHub (Jul 9, 2026): @0qie me too having the same issue yesterday and today as well.

saavagebueno commented

@WowAndAchja commented on GitHub (Jul 9, 2026):

today similar issue according to fable the node of netbird side 54.37.79.68 is ded had to put a record instead of cname to 57.129.98.79 and it worked

same problem

@WowAndAchja commented on GitHub (Jul 9, 2026): > today similar issue according to fable the node of netbird side 54.37.79.68 is ded had to put a record instead of cname to 57.129.98.79 and it worked same problem

saavagebueno commented

@logdotexe commented on GitHub (Jul 10, 2026):

same problem, but if I try to create a service with the free netbird domain and not my custom one, everything works fine even if the IP is always 54.37.79.68

@logdotexe commented on GitHub (Jul 10, 2026): same problem, but if I try to create a service with the free netbird domain and not my custom one, everything works fine even if the IP is always 54.37.79.68

saavagebueno commented

@Bajahaw commented on GitHub (Jul 10, 2026):

57.129.98.79 is down now, had to point the record back to 54.37.79.68

@Bajahaw commented on GitHub (Jul 10, 2026): 57.129.98.79 is down now, had to point the record back to 54.37.79.68

saavagebueno commented

@0qie commented on GitHub (Jul 10, 2026):

This is god awfull, are the people at netbird seeing this? Today my sites went down again. Seems like I was not the only one.

@0qie commented on GitHub (Jul 10, 2026): This is god awfull, are the people at netbird seeing this? Today my sites went down again. Seems like I was not the only one.

saavagebueno commented

@0qie commented on GitHub (Jul 10, 2026):

it's down again lads

@0qie commented on GitHub (Jul 10, 2026): it's down again lads

saavagebueno commented

@Bajahaw commented on GitHub (Jul 10, 2026):

did anybody moved out from cloud and solved this issue?

@Bajahaw commented on GitHub (Jul 10, 2026): did anybody moved out from cloud and solved this issue?

saavagebueno commented

@timharek commented on GitHub (Jul 10, 2026):

It's been an ongoing issue for a while it seems. People have been reporting this in their community Slack (me included).

Remember that the reverse proxy feature is still in beta, and is totally free for the time being. Have patience and be helpful.

@timharek commented on GitHub (Jul 10, 2026): It's been an ongoing issue for a while it seems. People have been reporting this in their community Slack (me included). Remember that the reverse proxy feature is still in beta, and is totally free for the time being. Have patience and be helpful.

saavagebueno commented

@SeverinPaar commented on GitHub (Jul 12, 2026):

I have been facing the same issue for a couple days, does someone have a workaround?

@SeverinPaar commented on GitHub (Jul 12, 2026): I have been facing the same issue for a couple days, does someone have a workaround?

saavagebueno commented

@0qie commented on GitHub (Jul 12, 2026):

Switching ip's doesn't seem to work properly anymore. You now have to delete the netbird reverse proxy services and still point the the correct CNAME. Atleast this works for me now..

@0qie commented on GitHub (Jul 12, 2026): Switching ip's doesn't seem to work properly anymore. You now have to delete the netbird reverse proxy services and still point the the correct CNAME. Atleast this works for me now..

saavagebueno commented

@Bajahaw commented on GitHub (Jul 12, 2026):

@SeverinPaar I have been facing the same issue for a couple days, does someone have a workaround?

I tried the new self-hosted cluster, seems to avoid the issue public services, but I am facing other issues in auth, not recommending it for now.

@Bajahaw commented on GitHub (Jul 12, 2026): > @SeverinPaar I have been facing the same issue for a couple days, does someone have a workaround? I tried the new self-hosted cluster, seems to avoid the issue public services, but I am facing other issues in auth, not recommending it for now.

saavagebueno commented

@Turnspit8472 commented on GitHub (Jul 13, 2026):

Had the same issue on selfhosted - it initially worked for around a day, then got stuck in a loading-loop until showing a 502-error.

Troubleshot every step of the whole route (thought it was a cloudflare-issue at first), but it indeed seems like the netbird-server loses its connection to the (routing) peer regarding the proxy-portion of the whole stack, while still being able to ping it and reach everything else it's supposed to reach. Restarting the (routing) peer resolved the issue, but only temporarily again.

What fixed it for me:
Disabling "Lazy Connections" (Settings -> Clients), which was enabled by default on my install. Absolutely 100% stable since then.

@Turnspit8472 commented on GitHub (Jul 13, 2026): Had the same issue on selfhosted - it initially worked for around a day, then got stuck in a loading-loop until showing a 502-error. Troubleshot every step of the whole route (thought it was a cloudflare-issue at first), but it indeed seems like the netbird-server loses its connection to the (routing) peer regarding the proxy-portion of the whole stack, while still being able to ping it and reach everything else it's supposed to reach. Restarting the (routing) peer resolved the issue, but only temporarily again. What fixed it for me: Disabling "Lazy Connections" (Settings -> Clients), which was enabled by default on my install. Absolutely 100% stable since then.

saavagebueno commented

@0qie commented on GitHub (Jul 13, 2026):

I switched to cloudflare.. was a bit annoying to set-up tbh, Netbird wins on that but totally not stable. I let you guys inform if I have the same bs over there

Edit: Cloudflare works so far with no issues

@0qie commented on GitHub (Jul 13, 2026): I switched to cloudflare.. was a bit annoying to set-up tbh, Netbird wins on that but totally not stable. I let you guys inform if I have the same bs over there Edit: Cloudflare works so far with no issues

saavagebueno commented

@Bajahaw commented on GitHub (Jul 13, 2026):

Disabling "Lazy Connections" (Settings -> Clients), which was enabled by default on my install. Absolutely 100% stable since then.

I have lazy connection disabled, tried enabling then disabling, still down.

I am also using CF for http services, It's rock solid, but you cannot expose public TCP services there, I have couple of those unfortunately,

@Bajahaw commented on GitHub (Jul 13, 2026): > Disabling "Lazy Connections" (Settings -> Clients), which was enabled by default on my install. Absolutely 100% stable since then. I have lazy connection disabled, tried enabling then disabling, still down. I am also using CF for http services, It's rock solid, but you cannot expose public TCP services there, I have couple of those unfortunately,

saavagebueno commented

https://github.com/netbirdio/netbird/discussions/6639#discussioncomment-17611659

@mrtn-roeder commented on GitHub (Jul 13, 2026):

@mrtn-roeder commented on GitHub (Jul 13, 2026): https://github.com/netbirdio/netbird/discussions/6639#discussioncomment-17611659

saavagebueno commented

@SeverinPaar commented on GitHub (Jul 14, 2026):

I didn't change anything, but the issue seems to have gotten fixed overnight! Let's hope it stays that way. Can someone else confirm it is fixed for them as well?

@SeverinPaar commented on GitHub (Jul 14, 2026): I didn't change anything, but the issue seems to have gotten fixed overnight! Let's hope it stays that way. Can someone else confirm it is fixed for them as well?

saavagebueno commented