Analyzing Caddy's log files real time with GoAccess?

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?

Thanks!

[1] [Help] Realtime HTML not working · Issue #1577 · allinurl/goaccess · GitHub

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.

Thank you for the detailed answer Matthew.

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)?

Thanks

By the way, is there a way to automatically redirect HTTPS requests to HTTP (not viceversa)?

No :wink:

I understand Matt :slight_smile:

However, it still seems strange to me that nobody is able to use goaccess with Caddy in HTTPS without having to expose port 7890.

There should be a way to do it, I guess…

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.

1 Like

You mean that it is possible with Caddy 1.x? If so, what basically I still need to decide (honest question)?

I’d like to have a reverse proxy on port :82 with a websocket connection on port :7890 without having to open other ports than 80 and 443.

Thanks!

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.

I mean open outside the LAN, I was not clear sorry.

Basically, ports 80 and 443 open outside the LAN and ports 82 and 7890 within the LAN.

Then you need to:

  1. Configure Caddy with one site that reverse proxies back to port 82
  2. Configure Caddy with a second site (a subdomain maybe) that reverse proxies websockets to 7890
  3. Configure GoAccess to point the websocket client at the second site
  4. Browsing to the first site should now work with live updating

Thanks Matthew, but I am not sure to understand.

I take your points:

  1. This is the same config I have above
  2. I create another reverse proxy on port 7890
  3. This is what I do not understand. What should I do in particular?

Would you be able to provide an example of step 3?

Thanks!

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.

GoAccess - Manual Page

Ok, what you are saying is something like this.

On Caddy.conf:

sub.domain.com {
       import gzipconf
       import addheader
       log /share/Public/GoAccessLogs/goaccess-access.log
       proxy / http://192.168.10.37:82 {
                keepalive 32
                transparent
                websocket
        }
}

wss.domain.com {
       import gzipconf
       import addheader
       log /share/Public/GoAccessLogs/goaccess-access.log
       proxy / http://192.168.10.37:7890 {
                keepalive 32
                transparent
                websocket
        }
}

On the GoAccess starting path:

goaccess --no-global-config -o /share/Web/goaccess/index.html --real-time-html --config-file=/share/Public/script/goaccess/goaccess.conf --geoip-database /share/Public/script/goaccess/GeoIP/GeoLite2-City.mmdb –ws-url=wss://wss.domain.com

Then if I go to sub.domain.com I should have the live update.

Is that correct? Thank you!

Looks pretty good to me! Did you give it a shot? How’d it do?

I tried, but it seems there is an error somewhere. I will check (with a desktop chrome) and see where the problem is (maybe a simple misspell).

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.

[1] https://www.websocket.org/echo.html

Go to the network tab again and see what URL your browser is trying to connect to, and what response, if any, it got?

I finally managed to find a Chrome on a desktop :slight_smile:

The result I got was:

WebSocket connection to 'wss://wss.domain.com:7890/' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
setWebSocket @ (index):27
initialize @ (index):27
window.onload @ (index):27

However if I directly went to wss.domain.com I did not have any problem and with netstat port 7890 was open.

I have then realized than just declaring port 443 would do the trick: --ws-url=wss://wss.domain.com:443.

Thank you!

Hi Matthew,

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.

Is there a way to log this as well? Thanks!