Overview

Protocol asymmetry means different clients and servers get different results depending on how they reach you, rather than everyone seeing the same problem. This is different from general network issues, which affect connectivity regardless of address or protocol.

It shows up in two ways:

• A whole protocol fails to connect. The connectivity tester reports every IPv6 (or IPv4) address as unreachable while the other family works fine.
• /.well-known/matrix/server disagrees depending on which address answered. Some servers get a correct response, others get an error, a timeout, or a different target entirely, purely based on which of your addresses they happened to reach. This is sometimes called "split-brain."

Both usually come down to one of two underlying causes: a dual-stack issue, where IPv4 and IPv6 behave differently, or a resolution issue, where your domain resolves to more than one address and those addresses don't all lead to the same, correctly configured backend.

Most Matrix server implementations retry across every resolved address rather than giving up after the first one, so a server that can reach any working address usually still gets through. The real harm falls on whichever servers happen to be locked to the broken address, most commonly an IPv6-only server when your IPv6 side is the broken one. It's shut out entirely, even though your server looks perfectly healthy to everyone testing over IPv4.

Dual-stack issues

These affect one protocol while the other keeps working.

Firewall rules for only one protocol

iptables and ip6tables are separate rule sets. It's easy to open port 443/8448 in one and forget the other, especially if IPv6 support was added to your server after the firewall was first configured.

Missing or incorrect AAAA record

If your A record is correct but there is no AAAA record (or it points at the wrong address), IPv6-preferring clients and servers will fail to connect even though IPv4 works fine.

No real IPv6 route

Some hosting providers assign an IPv6 address that isn't actually routed, or a container/VM only has IPv6 configured on an internal network interface rather than a publicly reachable one.

Reverse proxy only listening on one family

A reverse proxy explicitly bound to an IPv4 socket (e.g. listen 443; in some Nginx configs, which defaults to IPv4-only unless listen [::]:443; is also present) will silently refuse IPv6 connections even if the OS itself has an IPv6 address.

Resolution issues

These affect a subset of your addresses regardless of protocol, because your domain resolves to more than one address and those addresses don't lead to the same place.

DNS still pointing at a decommissioned host

If you migrated your server to a new address but an old A/AAAA record (or a secondary one) still points at the previous host, that old host may no longer serve the current well-known content, or may not respond at all.

Multiple reverse proxy nodes with divergent config

If you run more than one reverse proxy node behind different addresses (for redundancy or load balancing), each one needs the exact same configuration. A node that missed the last deployment will keep serving its old or default response.

Stale SRV record used as a silent fallback

SRV only comes into play in two specific cases: your well-known delegates to a hostname without an explicit port, or the well-known lookup fails outright. In both cases, resolution falls through to an _matrix-fed._tcp SRV lookup (and from there to plain A/AAAA on port 8448 if no SRV record exists). If that fallback target is stale, left over from a previous setup, servers that hit this fallback path (an intermittent well-known failure on one address, say) land on a different backend than servers that got a normal, direct well-known response. See Well-Known Delegation for the full precedence order.

Diagnosing it

Test both protocols explicitly against your domain:

curl -4 https://matrix.example.com/_matrix/federation/v1/version
curl -6 https://matrix.example.com/_matrix/federation/v1/version

Confirm the DNS side:

dig +short A matrix.example.com
dig +short AAAA matrix.example.com

Check what's actually listening:

sudo ss -tlnp | grep 443

An entry showing 0.0.0.0:443 only (no [::]:443 or *:443 line) means nothing is listening on IPv6 at all. The problem is local, not network-level.

If you suspect well-known itself disagrees per address, query it directly against each address your domain resolves to, forcing the request to that one instead of letting DNS pick for you:

# Repeat for every address your domain resolves to
curl --resolve example.com:443:203.0.113.10 https://example.com/.well-known/matrix/server
curl --resolve example.com:443:203.0.113.11 https://example.com/.well-known/matrix/server

Any address returning a different m.server value, a non-200 status, or no response at all is the broken one.

Fixing it

• Dual-stack issue you want to fix: correct the firewall rule, DNS record, or listener binding for the broken family, then re-test with curl -4/curl -6 until both succeed.
• Dual-stack issue you can't fix right now: remove the corresponding DNS record (usually AAAA) entirely, so every server only ever attempts the family that actually works. A half-configured second protocol is worse than not advertising it at all: it just causes intermittent failures for whichever servers pick it.
• Stale DNS: remove the record for the decommissioned host, or update it to point at the current server.
• Multiple reverse proxy nodes: re-deploy your configuration to every node, and confirm your deployment process actually reaches all of them.
• Stale SRV fallback: give your well-known delegation target an explicit port so SRV is never consulted at all, or update the SRV record to match your current backend if you need it as a genuine fallback.

Once every address behaves consistently (or the broken one is removed from DNS), re-run the connectivity tester to confirm the warning clears.

See Federation Network for the broader set of network and DNS checks federation depends on.