*.tlsfingerprint.io down?
hellodword opened this issue · 6 comments
$ q A AAAA tlsfingerprint.io @https://1.1.1.1
tlsfingerprint.io. 55s A 54.204.78.98
$ curl -v tlsfingerprint.io
* Trying 54.204.78.98:80...
* TCP_NODELAY set
* connect to 54.204.78.98 port 80 failed: Connection refused
* Failed to connect to tlsfingerprint.io port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to tlsfingerprint.io port 80: Connection refused
$ curl -v https://tlsfingerprint.io
* Trying 54.204.78.98:443...
* TCP_NODELAY set
* connect to 54.204.78.98 port 443 failed: Connection refused
* Failed to connect to tlsfingerprint.io port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to tlsfingerprint.io port 443: Connection refused
$ curl -v https://quic.tlsfingerprint.io
* Trying 54.204.78.98:443...
* TCP_NODELAY set
* connect to 54.204.78.98 port 443 failed: Connection refused
* Failed to connect to quic.tlsfingerprint.io port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to quic.tlsfingerprint.io port 443: Connection refused
$ curl -v https://client.tlsfingerprint.io:8443/
* Trying 54.204.78.98:8443...
* TCP_NODELAY set
* connect to 54.204.78.98 port 8443 failed: Connection refused
* Failed to connect to client.tlsfingerprint.io port 8443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to client.tlsfingerprint.io port 8443: Connection refused
Thanks for reporting. I can try to fix it later today.
Currently it is in a very unstable state and we have to monitor the state and manually reboot the service when it got killed for various reasons. We expect this problem to persist until we have enough funding to upgrade our servers 😃 (we are working on it)
Does it open-sourced? I guess we can try stuff like docker run --restart always --cpus 1.3 --memory 1G to limit resource usage and keep it online, even on a lowend VPS :)
It is open-sourced: https://github.com/refraction-networking/tls-fingerprint
The most recent (unrecoverable) crashing are mostly due to our customized caddy getting OOM-killed, which indicates either a memory leak problem (unlikely) or we simply don't have enough RAM available to handle such a high volume of concurrent requests.
AFAIK OOM-kill makes a service no longer being qualified for auto-restart, but I'm not really sure about that. (Edit: that's a false impression, I have checked that on OOM-kill a service can be auto-restarted) But anyways restarting-on-crash is simply not a long term solution.
Should be up.
Configured the systemd service to auto-restart. We should no longer see any extended downtime in the future.
Cool, thanks @gaukas
If you're using the systemd, I think you could try the resource control options, otherwise in some special cases, the issue process may uses up all resources and even causes ssh connection issue (maybe not true, but worth to limit it I guess😎).