Should I have a different *.log file for each site (and therefore have multiple log-file /path/to/access.log) or can I make each site pointing to the same *.log file?
Ok, I solved it: it seems that if you use the HTML layout you have to use an existing webserver. In my case I have one on port 82, so just I configured Caddy to that port and it works:
The index.html file is generated once at GoAccess startup and stays the same after that point. For live updating, the site connects you to a websocket which supplies the new information. If the websocket isn’t enabled or can’t connect, you’ll only ever get first-run data.
I checked and I receive the following error on the Google Chrome Dev Tool:
WebSocket connection to 'wss://sub.domain.com:7890/' failed: Establishing a tunnel via proxy server failed.
setWebSocket @ (index):28
initialize @ (index):28
window.onload @ (index):28
The problem could be originated by the fact that Caddy is set to look at http://192.168.10.37:82/goaccess/index.html (which is the port where my Apache Server is running, i.e. the sole location that I managed to make it accessible for reading the index.html file).
An externally-accessible reverse proxy to the GoAccess websocket
To have GoAccess point your browser at that externally-accessible URI
Caddy can handle the former quite easily (looks like you’re already doing this in your latest Caddyfile). The latter you’ll need to look into GoAccess’ own configuration options.
In practice you are saying to point the reverse proxy to port 7890 and to just look at the goaccess config file to find a directory which is accessible by the websocket to put the index.html, right?
Not 100% sure I understand what you mean by that, sorry.
The index file and websocket are handled very separately. One is a file served from the disk, the other is an upstream server you can reverse proxy to.
You need to configure GoAccess to announce the correct URI through which an external client can reach the websocket. Currently it’s announcing port 7890, which isn’t working.
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)?