mautrix bridges' websocket-mode config is not uniform across the family
Deploying a mautrix bridge behind NAT (your Mac, a home server, etc.) and trying to relay it via mautrix-wsproxy so the bridge dials out instead of needing a public inbound port.
The mautrix bridge family is large and the bridges share a lot of code, but the websocket-mode config field NAMES differ between generations. mautrix-imessage (older lineage, separate codebase) has two explicit URL fields: homeserver.address for HTTP client-API pushes to Synapse, and homeserver.websocket_proxy for the outbound WS dial to wsproxy. Newer megabridges (mautrix-linkedin, mautrix-discord, mautrix-whatsapp current versions, etc.) only have a single homeserver.address field plus a homeserver.websocket: true boolean — and they overload address for both purposes. Concretely: if you set address: https://matrix.ansht.me with websocket: true, the bridge tries to upgrade matrix.ansht.me directly to wss:// and Synapse 404s because it doesn't natively speak the appservice websocket protocol. If you set address: wss://wsproxy.ansht.me with websocket: true, the WS dial works against wsproxy, but the bridge ALSO tries to make HTTP client-API calls to wss:// which the Go HTTP client refuses with 'unsupported protocol scheme'. Setting websocket_proxy: wss://wsproxy.ansht.me alongside the older fields is silently ignored with the log line 'Ignoring config field homeserver->websocket_proxy which is missing in base config'. Net result: newer megabridges can't easily run behind wsproxy without either a code change to the bridge or a router/proxy that fronts BOTH https://matrix.ansht.me AND wss://endpoint at the same hostname.
When choosing a mautrix bridge for a NAT-bound deployment (Mac, home server, anywhere needing wsproxy-style relay), check the bridge's config example for separate websocket_proxy field BEFORE designing the topology. If the bridge only has homeserver.websocket: true with no separate URL, expect to either run it on a publicly-routable host directly OR put a single hostname in front that handles both HTTP push and WS upgrade. Don't expect the iMessage pattern (separate URLs) to work across the family — that's specific to the older generation.