QUIC misconfigured but ping says OK

Hello,
i’m running my node on version v1.123.4 and it is a little bit strange that i got the error that QUIC is misconfigured.

I did on pingdom a check and got the following:

- started
- 
- from: St.Petersburg, Russia
- QUIC: dialed node in 116ms
- QUIC: pinged node in 54ms
- QUIC: total: 169ms
- TCP: dialed node in 121ms
- TCP: pinged node in 55ms
- TCP: total: 176ms
- 
- from: OVH, France
- QUIC: dialed node in 114ms
- QUIC: pinged node in 22ms
- QUIC: total: 136ms
- TCP: dialed node in 126ms
- TCP: pinged node in 21ms
- TCP: total: 147ms
- 
- done.

So how do i get this misconfigured message away? Does anyone have a idea for me?

Thank you

I don’t know what your specific config issue is: but if you’re “Status = Online”, and your “Last Contact” is recent (or zero)… then your node is fine and QUIC status can be ignored.

1 Like
2 Likes

Hello @emitremmus,
Welcome back!

You may check the node itself (replace external.host.tld with your own domain or public IP): http://external.host.tld:28967, it should return something like

{
  "Statuses": null,
  "Help": "To access Storagenode services, please use DRPC protocol!",
  "AllHealthy": true
}

Yes, i got this message, when i try with my own domain.
{
“Statuses”: null,
“Help”: “To access Storagenode services, please use DRPC protocol!”,
“AllHealthy”: true
}

I’ve got this
{
“Statuses”: null,
“Help”: “To access Storagenode services, please use DRPC protocol!”,
“AllHealthy”: false
}
What’s wrong with my node?

Look in the dashboard. Likely low status.

1 Like

Hello, I have two nodes, each in a different house, with a different IP, different networks, and different hardware. Suddenly, I have the same “QUIC misconfigured” issue on both nodes. If I run a ping test, everything is OK. If I run this test, it looks fine:

{
“Statuses”: null,
“Help”: “To access Storagenode services, please use DRPC protocol!”,
“AllHealthy”: true
}

Could this be caused by a Storj update? Both nodes are running version v1.123.4.

Your node works correctly. What are you trying to debug?

If you simply don’t like red “misconfigured” text you have few options:

  • don’t open dashboard, so you won’t have to look at it.
  • remove it with ad blocker browser extension.
  • Read the linked thread for a potential workaround that may or may not work for your case.
1 Like

Hello, in the end, the “QUIC misconfigured” message resolved itself, now it shows “OK” on both nodes. I was worried because Storj sent me several messages like this: “Your Storage Node on the Saltlake satellite has gone offline. If your node remains offline, you may be suspended or disqualified.”
“Your Storage Node on the EU1 satellite has gone offline.If your node remains offline, you may be suspended or disqualified.”

Thanks.

QUIC connectivity is validated every hour, as far as I remember, so if it’s flaky, it may be tolling before ok and misconfigured.

That is a problem, and is not related to QUIC, it’s actual node reachability; satellite cannot reach your node. Make sure your DDNS solution is stable, and properly configured. Are you using any, or do you have static IP?

For example many here have good success with noip’s services, and no-one has any success with Asus.

Also check if you have any security solutions that may be dropping traffic in the way.

2 Likes

I thought QUIC connectivity was validated instantly after fixing the issue and refreshing the page. I use DuckDNS because it’s free. Isn’t it good?

It’s garbage.

Noip is recommended here often and has free option as well (of course, it’s only free if time is worthless – they want you jump through hoops monthly to keep it free).

If you have your own domain, your registrar may offer DDNS at no cost, or provide API you can use with some utilities. (For example, my domains are on Cloudflare, so I let inadyn update the A record programmatically. Because it’s cloudflare – it is rock solid.)

Generally, I would avoid free options. They usually turn out to be very expensive. For example, consider amount of time you have already spent debugging this issue, just because of illusion of “free” service. Paying $2 would be much cheaper.

3 Likes

I like the idea of buying a dirt-cheap domain from someone like porkbun… so you have near-infinite subdomains, and reliable dyndns.

Now that I think about it, I have several websites, and I checked that my domain registrar offers that option for free to its customers. I had no idea. Thanks again, I’ll switch as soon as I can. :slight_smile:

3 Likes

Why porkbun specifically?

I.e why pay more to some nobody when large established registrar charge less?

I’ll ask yet another way: why pay to reseller of cloudflare services (if my quick “research” did not led me astray) when you can eliminate a middleman — extra point of failure and extra expense — and get domain at cloudflare directly?

I use duckdns.org till now.
Second day in a row I’ve noticed that my disk space goes low and my trash space increases. My node is online but reported as misconfigured. Traffic to/from is normal like previous days. I’ll try to move my node to NOIP if I can manage to do that. Should this solve the problem with the trash?

What’s the problem with your trash? Every bloom filter will make some fresh trash… and a week later it gets deleted. You should expect to always have some.

As long as you don’t have trash directories that are too old (like I’d expect those going back to 2025-03-11 as of today) things are working fine.

1 Like

The same thing is happening to me. The ports are open and checked externally. The IP address is updated on duckdns.org. I have also tried restarting the node and nothing.

I’ve checked the integrity of all databases and found nothing wrong. *.db files on storagenode.

Today I’m starting to get very worried because two of my nodes are starting to penalize me. What can I do?

Right now, doing nothing. Like a miracle…

This makes me wonder how a node that’s online, that’s been running with a dyndns for years but with the same IP address, and that hasn’t changed, is penalized. Apparently, some servers weren’t reaching it for some reason beyond its control. Is there a mechanism to detect this and not penalize the node? If two other servers have connected to the node, I’d say it’s not down and the node shouldn’t be penalized…