tobychui
[BUG] TLS handshake errors in docker log for proxy hosts
Describe the bug
After adding a new host to zoraxy to be proxied, within the docker log, it looks like zoraxy is trying to connect via TLS to that host on rotating high port numbers.
zoraxy | 2024/07/28 13:32:46 http: TLS handshake error from 192.168.1.10:51454: EOF zoraxy | 2024/07/28 13:33:02 http: TLS handshake error from 192.168.1.10:50924: EOF zoraxy | [2024-07-28 13:33:09.218083] [internal] [system:info] mDNS Startup scan completed zoraxy | 2024/07/28 13:33:16 http: TLS handshake error from 192.168.1.10:54110: EOF zoraxy | 2024/07/28 13:33:46 http: TLS handshake error from 192.168.1.10:51688: EOF zoraxy | 2024/07/28 13:34:02 http: TLS handshake error from 192.168.1.10:59690: EOF
I can't see any reason for that, as this host only serves service at port 80/tcp which zoraxy should handle. As soon as I remove any host, the polling stops.
Whats causing this behavior? Any kind of keepalive/availability check?
To Reproduce Steps to reproduce the behavior:
- Add a new http proxy rule for a host
- Check the docker logs for the entry.
Expected behavior Either no automated polling and TLS connecting or an option to activate/deactivate. If it's some kind of keepalive/availability checking function, it should be configureable.
Host Environment (please complete the following information):
- Arch: amd64
- Device: VM
- OS: Debian
- Version Bookworm
- Docker Version (if you are running Zoraxy in docker): 27.1.1, build 6312585
@pkirsche That is the uptime monitor. I think you have an upstream mis-configed. Try uncheck the "Require TLS" in the upstream options.
Btw, talking about the random port, it is how TCP/IP works. In simple words, when a client connected to a given fixed listening port (e.g. 443), after the connection established, client is usually "redirected" to another "free" port (e.g. 54110) for future connections so the next client can connect to the fixed listening port. You can check out some university open lecture on computer networking.
@tobychui Thanks for the blazing fast response. Makes sense to me regarding the uptime monitor. Cool function by the way.
As suggested, I rechecked the upstream configuration again. The upstream host itself serves on port 8443 with self signed TLS certificate and my zoraxy configuration for this server should match with that. I activated and deactivated the "Require TLS", but as the upstream server serves via https, I should use "Require TLS here" I assume. Within the description above, I mentioned that the server is port 80 only, that was my mistake, sorry. Additionally I have "Skip verification" enabled, as the upstream host uses self-signed certificates.
Regarding the functionality, everything is working well with zoraxy (love it) and the server is reachable via zoraxy.
But regardless what I configure, I have these messages within the docker log every 30 seconds. Can I suppress them in any way?
@pkirsche No. it was from the dpcore and it is considered as important log (which means there is setup that goes wrong somewhere, maybe in your upstream?). If everything is running without issue, you can ignore them and they won't show up in Zoraxy log. But generally speaking, I would recommend you checking if you have setup everything properly & correctly.
I have had similar issue for all configured hosts. I did solve it, I had to re-create certificate cuz somehow ZORAXY decided to not renew WildCard. It did onlu for primary domain not for *.example.something. It happened after upgrade to latest.
@klisza1993
Interestingly though, there are no changes in the code regarding ACME and certificate auto-update process except of the early renew date is now user config-able via start parameters. So I guess it might be an independent bug that is not related to this issue. If you have got some free time, maybe you can create a new issue and include details on how to reproduce it?
I have had similar issue for all configured hosts. I did solve it, I had to re-create certificate cuz somehow ZORAXY decided to not renew WildCard. It did onlu for primary domain not for *.example.something. It happened after upgrade to latest.
Thanks for your tipp, I reissued my *.domain certificate through Zoraxy (worked well), but unfortunately it didn't solve the behavior for me. I still see these entries, also for every configured host. As soon as I delete one of the hosts, the log entries for this specific host stop immediately.
I've found a thread regarding the same entries, it seems to be GO related:
https://github.com/golang/go/issues/61721
Still very hopeful this can be solved.