Caddy/Matrix is no longer working -- it worked fine previously but I'm not sure what changed!

[emilylange]

The matrix federation server2server API runs on :8448 by default.
When some other homeserver tries to connect to you, it will do the following:

1. Check SRV records (might get deprecated)
2. Check /.well-known/matrix/server for something like { "m.server": "federation-endpoint.example.com:443" }
3. Connect either directly to the homeserver on :8448 or the delegated endpoint from either SRV or .well-known

So far, so good.
The federation tester https://federationtester.matrix.org/#matrix.naff.casa provides you with more than just “failed”.

Connection Errors

Get “https://98.167.142.137:8448/_matrix/key/v2/server”: context deadline exceeded (Client.Timeout exceeded while awaiting headers)

See the :8448 again?
So your delegation doesn’t seem to work.

Let’s check the .well-known ourselves:

❯ curl https://matrix.naff.casa/.well-known/matrix/server -i
HTTP/2 404 
alt-svc: h3=":443"; ma=2592000
content-type: text/plain
date: Fri, 02 Dec 2022 12:40:22 GMT
server: Caddy
server: Synapse/1.72.0
content-length: 42

404. Is anything ever truly *well* known?

Huh, that isn’t the response you configured in

@naffhouse

        header /.well-known/matrix/server {
                Content-Type application/json
        }
        respond /.well-known/matrix/server 200 {
                body "{ \"m.server\": \"matrix.naff.casa:443\" }"
                close
        }

Neither the header nor the respond works.
That’s odd.
And it reverse_proxyies instead?

*/me checks Caddyfile again o_O*

Your matrix.naff.casa is defined twice

@naffhouse

matrix.naff.casa {
#       enable logging
        log

        # .well-known is delegated from example.co.uk and served here
        header /.well-known/matrix/server {
                Content-Type application/json
        }
        respond /.well-known/matrix/server 200 {
                body "{ \"m.server\": \"matrix.naff.casa:443\" }"
                close
        }
#       .well-known delegate for client
        header /.well-known/matrix/client {
                Content-Type application/json
        }
        respond /.well-known/matrix/client 200 {
                body "{\"m.homeserver\": {\"base_url\": \"https://matrix.naff.casa\"}}"
                close
        }

        reverse_proxy /_matrix/* http://192.168.1.37:8008
        reverse_proxy /_synapse/client/* http://192.168.1.37:8008
}

matrix.naff.casa {
        reverse_proxy 192.168.1.37:8008
}

That explains the absence of the Content-Type application/json/respond and the presence of server: Synapse/1.72.0

However, that isn’t valid Caddyfile syntax.
So I would bet the Caddyfile you shared isn’t the one your Caddy actually uses right now. Instead, Caddy might be using some earlier version without the respond/header directives.
Check your logs, and you should see something along the lines of

Error: adapting config using caddyfile: ambiguous site definition: matrix.naff.casa

---

Also, I would highly recommend enclosing your jsons in ` so you don’t have to use \" everywhere.
And while you are at it, consider grouping the header and respond using handle or handle_path.
Please see Nginx return directive in caddy -- return json - #3 by emilylange for an example and what I mean by that.

---

@naffhouse

I tried re-creating my instance with an new post-gres database – thought that was the issue but it still won’t federate.

I hope that you kept your synapse’s signing key and didn’t nuke your postgres database tables.
See synapse admin FAQ - I have a problem with my server. Can I just delete my database and start again?