All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Cloudflare "Error 525 SSL handshake failed" on Hetzner server
Hi. I have this weird issue since early January.
I am hosting a domain on Hetzner server with multiple subdomains. Sometimes I got Error 525 SSL handshake
error and usually a reload will make that error go away.
I was using the same server, the same domain, the same Nginx configurations before this and I had to reinstall the server due to a problem and after that, I intermittently getting this 525 error code.
What I have tried:
- Upgrading and downgrading Nginx
- Enabling debugging in Nginx log, nothing get logged when this error shows up
- Deleting origin cert in Cloudflare and regenerate them
- Using letsencrypt cert
- Rebooting the server
There are few other things but I cannot recall.
I cannot think any differences between before and after reinstall. After reinstall, I got less files because I cleaned up, and I have IPv6 enabled. I disabled IPv6 before this and leave it enabled after reinstalling. I have tried allowing Nginx to only listen on IPv4, but it still happen.
Also I can access my server fine without Cloudflare proxy. This issue only happen sometimes when I turn on the proxy.
Anyone got an idea how to debug this? I have been patient for so long. I contacted Cloudflare but they suggest me to use FLEXIBLE **SSL Mode instead of **FULL which I am using now. I have no problem trying that but at least I want to pinpoint the cause first.
Any thoughts?
Thanks in advanced!
Edit:
- Hetzner auction server, 6TB Disk, 32GB RAM
Comments
Increase the error log level on nginx,
Increase value sysctl session time out,enable AES on CPU and Tune ssl on nginx :
I have enabled debug in nginx logging which is I believe the highest level. Nothing get logged when I am having the 525 error.
I have applied the
rcvbuf=64000 sndbuf=128000 backlog=20000 ssl http2
and will report to you later.Also I already have
ssl_session_cache
configured.@isunbejo Nope, still happening.
will this help?
https://community.cloudflare.com/t/community-tip-fixing-error-525-ssl-handshake-failed/44256
http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html
Unfortunately no. These are the results:
I am currently using intermediate config of https://ssl-config.mozilla.org/
try https://www.ssllabs.com/ssltest/
try move ssl related config out of server tag
This is the output
Remove then test on ssllabs or test on sslabs before and after?
Tested before, Got A for all
https://i.imgur.com/2la2lK1.png
click inside and check Handshake Simulation, if you got A, then it's your browser issue, some old browser?
It is not just me. My users, my Jellyfin, even support staff of Cloudflare can reproduce the error. Yes I have contacted Cloudflare directly and they say they can reproduce the error as well and we are still communicating through support ticket. But since I am on free plan, it is quite slow.
When getting 525 error, there is no error logged in Nginx error_log. A few browser refresh would solve the issue temporarily in browser. On something that cannot be refresh like downloader, android apps like Trandroid, you need to wait until the error gone by itself.
@JohnRoe Suffering the same issue as you, did you find any fix?
Also can you confirm your NIC model? Mine is Intel i219-LM
tcpdump to look what's going on on a packet level + another webserver (apache,litespeed,h2o) to check if they affected too.
Is the full cert chain in your config?
Turn off cloudflare and try this https://www.ssllabs.com/ssltest/
I got the same problem before.
I switched the SSL setting inside Cloudflare from Full to Flxible, then switched back to Full after 5 mins. It worked.
@comXyz What's you NIC model?
Too many different models :-?
I switched to different NIC but still get the same issue sometimes when network is under load.
Do you still the face the same issue sometimes?
I don't think it has anything to do with NIC @uptime88
I even had a similar problem in cloud. (Nuremberg / Falkenstein)
And I'm sure this issue is not related to Cloudflare.
I've encountered the same issue, from the NIC driver.
Just upgrade kernel to 4.17+
https://community.hetzner.com/tutorials/installing-the-r8168-driver?title=Installation_des_r8168-Treibers/en
Cloudflare ssl only support 1 level of subdomain. If you have sub.sub.domain.com, Cloudflare ssl won't work. You need to Grey it.
@yokowasis @appcomq @upme88
I believe it has nothing to do with Cloudflare at all. (or kernel, I have 4.19)
This problem only occurs when the network load is high, sometimes. (~10MB/s & ~1k PPS) (I use rsync to transfer files)
I did a lot of testing on this.
Both Nuremberg and Falkenstein can reproduce the problem. (CPX31/CX41)(AMD/Intel)
I think there is a fault with their firewall configuration. Looks like they "nullroute"(I don't know how to call it) my IP during the period.
E.g. (The results of nmap)
office.com - 80 port and 443 port is unreachable
github.com - 80 port and 443 port is unreachable
google.com - 80 port and 443 port is reachable
youtube.com - 80 port and 443 port is reachable
Cloudflare's IP - 80 port is reachable, but 443 port sometimes reachable, sometimes not.
The "nullroute" usually lasts for 10 to 30 minutes.
During this period I created a new cloud instance in the same data center, everything works fine.
@Hetzner_OL
@lighter
It may be caused by DDoS firewall.
I got the answer, From Hetzner technical support mail
Hello,
It is not possible to turn of the DDoS protection.
However the DDoS protection is not always active. It is only active when we detect an attack.
You can check that yourself with a mtr to your server. When a mitigation is active, there will be a hop called "ddos-mitigation"
One exception, when I upgraded to the 5.4 kernel, I didn't find any errors.
Thanks @appcomq . I will check it when it happens again.
But I prefer to use a stable kernel version. 4.19 is the latest kernel of debian 10.4.
I have already faced this problem, and it has nothing to do with SSL.
Cloudflare can send a lot of traffic to your server through just one IP, it can have packets rejected by your server's firewall (depending on the settings) or by your provider's firewall (DDoS protection).
The solution is to whitelist Cloudflare IPs for both firewalls (I'm not sure if Hetzner will do that).
https://www.cloudflare.com/ips/