From what I got here[1], it seems that the problem is that Caddy is requesting a wss and not a ws. Indeed I see that if I try to use the LAN IP to connect to goaccess, I have the “green dot” on it (meaning that the index.http is successful at establishing the websocks connection on port 7890).
Is there then any specific settings to use on Caddy?
This is probably a result of GoAccess being ambiguous on scheme and your browser is deciding to use WSS when it’s connected to the site over HTTPS. Connecting over HTTP will likewise result in a WS connection, which works over LAN.
Port 7890 is also probably not firewalled inside your internal network, but is it available externally? If you want, you can configure Caddy to listen on this port externally and proxy it to GoAccess internally, that’s one way about it.
There’s no magic setting to make this one just work. You need to decide where you want your index file to be publicly accessible, where you want the websocket to be publicly accessible, and you need to configure GoAccess to point a client (the browser) at the correct URI for the websocket. It’s entirely up to you as to how to organise things and whether, and where, you want Caddy to sit in between the client and the application.
Does this mean that no one here is using GoAccees through Caddy over HTTPS?
As the main purpose of putting something behind a reverse proxy is to do not open ports externally, I will not open port 7890, but I would probably just use HTTP.
However, would this current limitation be solved (with version 1.x or with the upcoming version 2.x of Caddy)?
It can be done - Caddy is exceptionally capable of handling this. You just need to make some decisions.
Once you’ve decided how you want it to work, I can point you at all the configuration docs you’ll need, and I can help you troubleshoot Caddyfile issues, but I won’t design your system for you.
Either I’m misunderstanding, or this is not possible. You can’t have external access to those ports but not have any ports open other than 80 and 443.
Caddy can serve those ports if you like, but that’s a fundamental limitation - ports you want to listen on must be open, or you naturally won’t be able to use them.
You can use this on GoAccess, either by command flag or by putting it in your configuration file, emphasis mine:
–ws-url=<[scheme://]url[:port]>
URL to which the WebSocket server responds. This is the URL supplied to the WebSocket constructor on the client side.
Optionally, it is possible to specify the WebSocket URI scheme, such as ws:// or wss:// for unencrypted and encrypted connections. e.g., wss://goaccess.io
If GoAccess is running behind a proxy, you could set the client side to connect to a different port by specifying the host followed by a colon and the port. e.g., goaccess.io:9999
By default, it will attempt to connect to the generated report’s hostname. If GoAccess is running on a remote server, the host of the remote server should be specified here. Also, make sure it is a valid host and NOT an http address.
The problem was on —ws-url= as I should have indicated wss://wss.domain.com. I can see here[1] that the connection is established, but I can’t still have a green dot on GoAccess index.html page.
I am continuing to experiment with Caddy (v. 1.04) and GoAccess and I realized that the latter does not provides stats on the browser used to access the site.