Get 522 error trying to connect to a proxied IPv6 only origin server

I configured an ipv6-only origin server and gave it a name in the cloudflare DNS. I made sure that proxying was off and I could connect to the server using that DNS name. This is GOOD.

However, turning proxying on for the single AAAA record (there is no A record for this name) just makes all connections fail with a 522 error. As far as I can see, no packets are received by the firewall in front of the origin server. This is BAD.

If I add an A record that points to another server, and then try to connect (proxied), then it connects me (presumably over IPv4) to the other server. This is what I would expect given that CF claims to prefer IPv4 over IPv6 to the origin server.

However, this leaves me in the state that I cannot enable proxying as then there is no connection.

From reading various other comments from users, it appears that some other people have this problem, and some others claim that it works. Does anybody have any ideas on the path forwards from here?


Out of curiosity, do you know if at your browser end, you’re using IPv4?

I’d try some ‘curl’ commands with a -4 and -6 to force the different connections and see what happens.

I was connecting over v6 when I was doing my initial testing from my phone (t-mobile prefers v6). I tried connecting over v4 and I still got the 522 error. [Both curl with -4 and -6 give 522 errors, though I actually only get a response body with -6 which tells me it is an origin connection timeout!]. Both connections appear to use the EWR datacenter based on the cf-ray header. I also tried using LAX and SJC clusters and the behavior was the same except that the LAX cluster gave me the origin connection timeout content on ipv4.

I do have ipv6 compatibility turned on.

That certainly seems reproducible. Can you open a ticket and post the ticket # here? Be sure to include a link to this thread. You can email them from your account’s email address → support AT cloudflare DOT com

It’ll probably auto-close the ticket, so be sure to reply and say you’re still getting the errors.

The ticket number is #2214316 – thanks.

1 Like

I’ve put this in the escalation queue. It’s a little slow on weekends, so someone should take a look by Monday.

I got the automated response that told me to check the things that I had already checked!

May I ask, can you resolve the IPv6 to hostname and vice-versa?

Recently I have had enabled IPv6 on my server which is still working over IPv4, but as I keep an eye on the traffic and requests, more and more of them are going over IPv6 and less over IPv4 (even Postfix configured to go over IPv6, preferred, while fallback to IPv4 for the hosts connecting only over IPv4).

I remember at first, I could not open few websites and I saw blocked Firewall events from the IPv6 of my server, for which I have had to allow/bypass it on Cloudflare for later.
Which now makes me thinking, was the Cloudflare connecting over IPv6, even if the AAAA records weren’t added for the main domain or a sub-domain like www, while the A and AAAA for “mail” hostname exist (other static IP on the network interface)?
Or, the server responded via IPv6 “mail” hostname somehow, instead from the added A record (IPv4 records) for main domain and www? - which could be something due to the settings on the server for the IPv6 forwarding being enalbed, while IPv4 forwarding disabled (I assume).

I have had to modify few things, re-check and add default route, and do reboot of the server at the end after all the steps considering the below:

  • etc/hosts
  • etc/hostname
  • etc/network/interfaces
  • etc/sysctl.conf
  • add the IPv6 to the eth interface, ip link set up, add the IPv6 default route
  • add rPTR record for that IPv6 in the provider’s server interface
  • add the IPv6 record :orange: to the Cloudflare DNS tab with correct hostname (the same as rPTR for that IP)
  • reboot server

That way, I could ping and resolve and ping from server via IPv6 to outside (like ping6 and vice-versa, from outside to inside (there was an issue regarding ping, as the one step was missing - the default route).

Maybe, by default, it should connect to IPv6, then fallback to IPv4.
Could it be something in between regarding the forwarding?

Either, if only AAAA records added to Cloudflare, it should go straight to it.

Regarding firewall, are Cloudflare IPv6 addresses allowed to connect, either to the host itself over the desired compatible ports with Cloudflare?

Forgot to ask, have you checked if your app/service is actually serving over IPv6 and if the, for example Nginx web server vhost file for that domain is configured to listen over an IPv6 on a desired port?

I have two entries in cloudflare for this test environment. They have identical AAAA records (and there are no A records). One has proxying on, and the other is in bypass. I can browse successfully to the bypass entry but not to the proxied entry. The firewall rule is configured to allow any incoming source ipv6 address. When browsing to the proxied entry, there is no entry in my nginx logs – which is not surprising as it gives me a 522 which implies that it couldn’t connect to my server.

The IPv6 connection to my server is via a hurricane electric tunnel.

Web server overload is one of the most common causes of error 522. It is impossible to predict the number of visitors at any given time. Intermittent load peaks mean that the server can’t keep up with processing HTTP requests – so you should keep an eye on the traffic development of your web project using analysis software. Evaluate the data regularly to identify bottlenecks and upgrade the hardware setup of the hosting environment . Flexible cloud hosting solutions enable you, for example, to scale resources with pinpoint accuracy so that you can react optimally to fluctuations caused by the time of day, day of the week, or season .

It turned out that Hurricane Electric blocks traffic to tunnels from Cloudflare. However, they don’t document this anywhere that I could find…

This was the root cause of my problems!



This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.