QUIC Misconfigured despite pingdom showing QUIC working

Node Operators troubleshooting
,
1

All of my node dashboards on one device (running docker rootless) are showing “QUIC: Misconfigured”. Using Pingdom, I see storj RPC ping succeed:

started

from: St.Petersburg, Russia
TCP: dialed node in 703ms
TCP: pinged node in 167ms
TCP: total: 870ms
QUIC: dialed node in 700ms
QUIC: pinged node in 168ms
QUIC: total: 868ms

from: OVH, France
TCP: dialed node in 654ms
TCP: pinged node in 156ms
TCP: total: 810ms
QUIC: dialed node in 669ms
QUIC: pinged node in 159ms
QUIC: total: 828ms

done.

This was working previously, and the only thing I think has changed in the setup recently is the addition of IPv6 support for my domain, but I see this pass with both IPv6 and IPv4 addresses of my node explicitly, and also with the domain.

On startup, the node logs:

May 05 23:59:50 <user> 37ad4ad2a3d9[2717]: 2026-05-06T06:59:50Z        WARN        contact:service        Your node is still considered to be online but encountered an error.        {"process": "storagenode", "satellite_id": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "error": "contact: failed to ping storage node using QUIC, your node indicated error code: 0, rpc: quic: timeout: no recent network activity"}
May 05 23:59:50 <user> 37ad4ad2a3d9[2717]: 2026-05-06T06:59:50Z        WARN        contact:service        Your node is still considered to be online but encountered an error.        {"process": "storagenode", "satellite_id": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "error": "contact: failed to ping storage node using QUIC, your node indicated error code: 0, rpc: quic: timeout: no recent network activity"}
May 05 23:59:50 <user> 37ad4ad2a3d9[2717]: 2026-05-06T06:59:50Z        WARN        contact:service        Your node is still considered to be online but encountered an error.        {"process": "storagenode", "satellite_id": "121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6", "error": "contact: failed to ping storage node using QUIC, your node indicated error code: 0, rpc: quic: timeout: no recent network activity"}
May 05 23:59:51 <user> 37ad4ad2a3d9[2717]: 2026-05-06T06:59:51Z        WARN        contact:service        Your node is still considered to be online but encountered an error.        {"process": "storagenode", "satellite_id": "1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE", "error": "contact: failed to ping storage node using QUIC, your node indicated error code: 0, rpc: quic: timeout: no recent network activity"}

and I don’t ever see the status change (including on node restart).

I have another server running docker rootless on a different network (IPv4 only) and those are all reporting “QUIC OK”.

Both the server where all nodes have QUIC working, and the one with all nodes with QUIC reporting Misconfigured but seemingly working are storj version v1.152.6.

Any ideas why it’s reporting misconfigured? Given the pingdom report of QUIC success, is this just a dashboard bug, or is it really indicative of a setup issue?

2

Case closed.

3

Thanks, I assumed that might not be it since it mentions FreeBSD (I’m running Linux) and it was opened three years ago (mine just regressed recently). But if the whole feature is effectively deprecated I can happily ignore the warnings.

4

This sounds like your configuration is changed recently, because there was no changes related to QUIC for a long time.
You may try to use a workaround:

5

Trying to set server.address in config to any of hostname -i’s output within the image, or 0.0.0.0, or my router IP (can’t bind), or my server IP (can’t bind) all don’t seem to work. Seems like things are complicated a bit since it’s running in Docker. I’ll just keep it the way it was with QUIC misconfigured since this doesn’t seem like a concerning issue.

This sounds like your configuration is changed recently

Possibly related to IPv6 support in domain and router in my case, or some other host system software changes, but I’m not too sure.. I haven’t actually touched storj configs in a long time.

Thanks for the support anyway :slight_smile:

6

In the case of docker, you may try to bind the listening port to the one of your cards, connected to the internet directly or via router. QUIC Misconfigured is often related to setups where you have more than a one network interface, and listening at 0.0.0.0 on the host could cause QUIC not working.
E.g.:

...
-p 192.168.1.64:28967:28967/tcp \
-p 192.168.1.64:28967:28967/udp \
...

You may also try to use a --network host option before the image name, this will disable docker’s NAT and node will listen directly on the host without NAT, so you also need to make sure that all used ports are unique for your host.

7

I tried passing in the host network IP explicitly to docker’s port passthrough, and that doesn’t resolve the “misconfigured” reporting in the dashboard (but still shows success with Pingdom). It does break my IPv6 connection though which was working properly.

--network host fails due to insufficient permission since I’m running docker rootless. That could be resolved, but given pingdom’s success, is there even a networking issue here? Or is this possibly a purely reporting problem?

8

If the Misconfigured flag in the dashboard bothers you – you need to:

  • ensure you have only one adapter and bind to a specific IP
  • avoid docker (run the storagenode directly, or with podman if you have to).
  • ensure port number does not change through DNAT and various forwards.

If this still does not help – stop looking at dashboard and ignore the misconfigured flag. The flag is updated once an hour, and the issue is random. it can work for some packets and fail for others.

But as it was already pointed out repeatedly, clients don’t use QUIC. Clients use TCP. If you want to actually improve performance – focus on ensuring TFO works. This, unlike QUIC, actually helps latency.

If you want to fix the issue “just because” – you would need to dig into upstream go libraries. Bug was introduced there.

9

focus on ensuring TFO works

It does, including within the docker containers on all of my nodes across multiple servers.

The flag is updated once an hour, and the issue is random. it can work for some packets and fail for others.

I can ignore it as a low priority issue, just the explanation of it being networking (while pingdom works) or version based (while my other servers on the same version work) seems suspect, and I don’t observe it being flaky in my dashboard (always “misconfigured”) or with pingdom (always working) across many tests and many days. I’d think reporting QUIC support then having clients fail to connect could add a full round trip delay, even if not many clients are using QUIC at the moment.

If there’s really no networking issue I’m happy to just wait for this to be resolved upstream somewhere.

10

These use different paths probably. Check these threads:

All connections are concurrent, the fastest one wins. there is no extra delay

11

Just to follow up on what the cause of my issue actually was:

My AAAA record for my storj subdomain had become out of date (prefix from ISP changed) but my A record was still correct. When I fixed this all my storj nodes under this subdomain are showing “QUICK OK” on the dashboard again. When I was testing with pingdom I would try the domain (where I guess it fell back to A), or the IPv4, or the IPv6, all of which worked, but i guess something about the dashboard’s test checks the AAAA which would correctly fail.

12

The Storj network supports IPv6, but IPv4 is required, so dual stack is best.