docs: Rename "Advanced" section to "Guides"

2026-11-15 13:16:56 +00:00 · 2026-07-09 18:20:37 +00:00
1 parent 7e6bb7822e
commit bdb29a7f51
@@ -0,0 +1,302 @@
+# Delegation/split-domain deployment
+
+Matrix allows clients and servers to discover a homeserver's "true" destination via **`.well-known` delegation**. This is especially useful if you would like to:
+
+- Serve Continuwuity on a subdomain while having only the base domain for your usernames
+- Use a port other than `:8448` for server-to-server connections
+
+This guide will show you how to have `@user:example.com` usernames while serving Continuwuity on `https://matrix.example.com`. It assumes you are using port 443 for both client-to-server connections and server-to-server federation.
+
+## Configuration
+
+First, ensure you have set up A/AAAA records for `matrix.example.com` and `example.com` pointing to your IP.
+
+Then, ensure that the `server_name` field matches your intended username suffix. If this is not the case, you **MUST** wipe the database directory and reinstall Continuwuity with your desired `server_name`.
+
+Then, in the `[global.well_known]` section of your config file, add the following fields:
+
+```toml
+[global.well_known]
+
+# defaults to port :443 if not specified
+client = "https://matrix.example.com"
+
+# port number MUST be specified
+server = "matrix.example.com:443"
+
+# (optional) customize your support contacts
+# Defaults to members of the admin room if unset
+#support_page =
+#support_role = "m.role.admin"
+#support_email =
+#support_mxid = "@user:example.com"
+```
+
+Alternatively if you are using Docker, you can set the `CONTINUWUITY_WELL_KNOWN` environment variable as below:
+
+```yaml
+services:
+  continuwuity:
+    ...
+    environment:
+      CONTINUWUITY_WELL_KNOWN: |
+        {
+        client=https://matrix.example.com,
+        server=matrix.example.com:443
+        }
+
+      # You can also configure individual `.well-knowns` like this
+      # CONTINUWUITY_WELL_KNOWN__CLIENT: https://matrix.example.com
+      # CONTINUWUITY_WELL_KNOWN__SERVER: matrix.example.com:443
+```
+
+After doing the steps above, Continuwuity will serve these 3 JSON files:
+
+- `/.well-known/matrix/client`: for Client-Server discovery
+- `/.well-known/matrix/server`: for Server-Server (federation) discovery
+- `/.well-known/matrix/support`: admin contact details (strongly recommended to have)
+
+To enable full discovery, you will need to reverse proxy these paths from the base domain back to Continuwuity.
+
+## Reverse proxying well-known files to Continuwuity
+
+<details>
+
+<summary>For **Caddy**</summary>
+
+```
+matrix.example.com:443 {
+  reverse_proxy 127.0.0.1:8008
+}
+
+example.com:443 {
+  reverse_proxy /.well-known/matrix* 127.0.0.1:8008
+}
+```
+
+</details>
+
+<details>
+
+<summary>For **Traefik** (via Docker labels)</summary>
+
+```
+services:
+  continuwuity:
+    ...
+    labels:
+      - "traefik.enable=true"
+      - "traefik.http.routers.continuwuity.rule=(Host(`matrix.example.com`) || (Host(`example.com`) && PathPrefix(`/.well-known/matrix`)))"
+      - "traefik.http.routers.continuwuity.service=continuwuity"
+      - "traefik.http.services.continuwuity.loadbalancer.server.port=8008"
+```
+
+</details>
+
+
+For **Docker** users, consult the compose files in the [Appendix section](#docker-compose-examples).
+
+After applying these changes, restart Continuwuity and your reverse proxy.Visit these routes and check that the responses match the examples below:
+
+<details open>
+
+<summary>`https://example.com/.well-known/matrix/server`</summary>
+
+```json
+{ "m.server": "matrix.example.com:443" }
+```
+
+</details>
+
+<details open>
+
+<summary>`https://example.com/.well-known/matrix/client`</summary>
+
+```json
+{
+  "m.homeserver": {
+    "base_url": "https://matrix.example.com/"
+  }
+}
+```
+
+</details>
+
+### Serving well-known files manually
+
+Instead of configuring `[global.well_known]` options and reverse proxying well-known URIs, you can serve these files directly as static JSON that match the ones above. This is useful if your base domain points to a different physical server, and reverse proxying isn't feasible.
+
+<details>
+
+<summary>Example Caddyfile **for the base domain**</summary>
+
+```
+https://example.com {
+
+    respond /.well-known/matrix/server 200 {
+        body `{"m.server":"matrix.example.com:443"}`
+    }
+
+    handle /.well-known/matrix/client {
+    header Access-Control-Allow-Origin *
+    respond <<JSON
+    {
+        "m.homeserver": {
+            "base_url": "https://matrix.example.com/"
+        }
+    }
+    JSON
+    }
+}
+```
+
+</details>
+
+Remember to set the `Access-Control-Allow-Origin: *` header in your `/.well-known/matrix/client` path for web clients to work.
+
+## Troubleshooting
+
+Check that other servers can connect to you.
+Here are some tools that can help identify federation issues:
+
+- [Matrix Connectivity Tester](https://federationtester.mtrnord.blog/)
+- [Matrix Federation Tester](https://federationtester.matrix.org/)
+
+### Cannot log in with web clients
+
+Make sure there is an `Access-Control-Allow-Origin: *` header in your `/.well-known/matrix/client` path. While Continuwuity serves this header by default, it may be dropped by reverse proxies or other middlewares.
+
+### Issues with alternative setups
+
+As Matrix clients prioritize well-known URIs for their destination, this can lead to issues with alternative methods of accessing the server that doesn't use a publicly routeable IP and domain name. You will probably find yourself connecting to non-existent/undesired URLs in certain cases like:
+
+- Accessing to the server via localhost IPs (e.g. for testing purposes)
+- Accessing the server from behind a VPN, or from alternative networks (such as from an onionsite)
+
+In these scenarios, further configurations would be needed. Refer to the [Related Documentation](#related-documentation) section for resolution steps and see how they could apply to your use case.
+
+---
+
+## Using SRV records (not recommended)
+
+:::warning
+The following methods are **not recommended** due to increased complexity with little benefits. If you have already set up `.well-known` delegation as above, you can safely skip this part.
+:::
+
+The following methods uses SRV DNS records and only work with federation traffic. They are only included for completeness.
+
+<details>
+
+<summary>Using only SRV records</summary>
+
+If you can't set up `/.well-known/matrix/server` on :443 for some reason, you can set up a SRV record (via your DNS provider) as below:
+
+- Service and name: `_matrix-fed._tcp.example.com.`
+- Priority: `10` (can be any number)
+- Weight: `10` (can be any number)
+- Port: `443`
+- Target: `matrix.example.com.`
+
+On the target's IP at port 443, you must configure a valid route and cert for your server name, `example.com`. Therefore, this method only works to redirect traffic into the right IP/port combo, and can not delegate your federation to a different domain.
+
+</details>
+
+<details>
+
+<summary>Using SRV records + .well-known</summary>
+
+You can also set up `/.well-known/matrix/server` with a delegated domain but no ports:
+
+```toml
+[global.well_known]
+server = "matrix.example.com"
+```
+
+Then, set up a SRV record (via your DNS provider) to announce the port number as below:
+
+- Service and name: `_matrix-fed._tcp.matrix.example.com.`
+- Priority: `10` (can be any number)
+- Weight: `10` (can be any number)
+- Port: `443`
+- Target: `matrix.example.com.`
+
+On the target's IP at port 443, you'll need to provide a valid route and cert for `matrix.example.com`. It provides the same feature as pure `.well-known` delegation, albeit with more parts to handle.
+
+</details>
+
+<details>
+
+<summary>Using SRV records as a fallback for .well-known delegation</summary>
+
+Assume your delegation is as below:
+
+```toml
+[global.well_known]
+server = "example.com:443"
+```
+
+If your Continuwuity instance becomes temporarily unreachable, other servers will not be able to find your `/.well-known/matrix/server` file, and defaults to using `server_name:8448`. This incorrect cache can persist for a long time, and would hinder re-federation when your server eventually comes back online.
+
+If you want other servers to default to using port :443 even when it is offline, you could set up a SRV record (via your DNS provider) as follows:
+
+- Service and name: `_matrix-fed._tcp.example.com.`
+- Priority: `10` (can be any number)
+- Weight: `10` (can be any number)
+- Port: `443`
+- Target: `example.com.`
+
+On the target's IP at port 443, you'll need to provide a valid route and cert for `example.com`.
+
+</details>
+
+---
+
+## Related Documentation
+
+See the following Matrix Specs for full details on client/server resolution mechanisms:
+
+- [Server-to-Server resolution](https://spec.matrix.org/v1.17/server-server-api/#resolving-server-names) (see this for more information on SRV records)
+- [Client-to-Server resolution](https://spec.matrix.org/v1.17/client-server-api/#server-discovery)
+- [MSC1929: Homeserver Admin Contact and Support page](https://github.com/matrix-org/matrix-spec-proposals/pull/1929)
+
+## Appendix
+
+### Docker Compose examples
+
+The following Compose files are taken from [Docker instructions](../deploying/docker.mdx) and reconfigured to support split-domain delegation. Note the updated `CONTINUWUITY_WELL_KNOWN` variable and relevant changes in reverse proxy rules.
+
+<details>
+<summary>Caddy (using Caddyfile) - delegated.docker-compose.with-caddy.yml ([view raw](/advanced/delegated.docker-compose.with-caddy.yml))</summary>
+
+```yaml file="../public/advanced/delegated.docker-compose.with-caddy.yml"
+
+```
+
+</details>
+
+<details>
+<summary>Caddy (using labels) - delegated.docker-compose.with-caddy-labels.yml ([view raw](/advanced/delegated.docker-compose.with-caddy-labels.yml))</summary>
+
+```yaml file="../public/advanced/delegated.docker-compose.with-caddy-labels.yml"
+
+```
+
+</details>
+
+<details>
+<summary>Traefik (for existing setup) - delegated.docker-compose.for-traefik.yml ([view raw](/advanced/delegated.docker-compose.for-traefik.yml))</summary>
+
+```yaml file="../public/advanced/delegated.docker-compose.for-traefik.yml"
+
+```
+
+</details>
+
+<details>
+<summary>Traefik included - delegated.docker-compose.with-traefik.yml ([view raw](/advanced/delegated.docker-compose.with-traefik.yml))</summary>
+
+```yaml file="../public/advanced/delegated.docker-compose.with-traefik.yml"
+
+```
+
+</details>
@@ -0,0 +1,169 @@
+# DNS Tuning (recommended)
+
+For federation, Matrix homeservers conduct an enormous amount of DNS requests, sometimes up to thousands of queries per minute. Normal DNS resolvers are simply not designed for this load, and running Continuwuity with them will likely result in various [DNS and federation errors](../troubleshooting#dns-issues).
+
+To solve this issue, it is strongly recommended to self-host a high-quality, external caching DNS resolver for Continuwuity. This guide will use [Unbound][unbound] as the recommended example, but the general principle applies to any resolver.
+
+[unbound]: https://wiki.archlinux.org/title/Unbound
+
+## Overview
+
+For generic deployments, install your resolver of choice and configure `/etc/resolv.conf` to point to it. The resolver should ideally reside on the same host as Continuwuity.
+
+```txt title="/etc/resolv.conf"
+nameserver 127.0.0.1
+```
+
+**Avoid using `systemd-resolved`** as it does **not** perform very well under high load, and we have identified its DNS caching to not be very effective.
+
+### For Docker users
+
+Docker bridge networks uses a non-performant resolver to intercept and respond to container hostnames, and **this should also be avoided**. Instead, mount a custom `/etc/resolv.conf` file into the container, and hardcode a resolver address to bypass Docker's.
+
+It is recommended to run a dedicated resolver container for Continuwuity, as to separate from the host's resolver setup. To do this, create a custom bridge network and IP range, and explicitly define an IP address for the resolver container.
+
+<details>
+<summary>Example Docker deployment with unbound</summary>
+
+```yaml title="docker-compose.yml"
+networks:
+  matrix_net:
+    ipam:
+      driver: default
+      config:
+        - subnet: "10.10.10.0/24"
+
+services:
+    homeserver:
+        # ...
+        volume:
+            - ./continuwuity-resolv.conf:/etc/resolv.conf:ro
+
+    unbound:
+        # ...
+        networks:
+            matrix_net:
+                ipv4_address: 10.10.10.20
+```
+
+```txt title="continuwuity-resolv.conf"
+nameserver 10.10.10.20
+```
+
+</details>
+
+### For IPv4-only users
+
+If you don't have IPv6 connectivity, changing `ip_lookup_strategy` to only resolve for IPv4 will reduce unnecessary AAAA queries.
+
+```toml title="continuwuity.toml"
+[global]
+# 1 - Ipv4Only (Only query for A records, no AAAA/IPv6)
+ip_lookup_strategy = 1
+```
+
+## Unbound
+
+[Unbound][unbound] is the recommended resolver to run with Continuwuity. For Docker users, the `docker.io/madnuttah/unbound` image ([Github repo][madnuttah-unbound-repo]) can be used.
+
+After installation, you can tune `/etc/unbound/unbound.conf` values according to your needs. While Continuwuity cannot recommend a "works-for-everyone" Unbound DNS setup guide, the official [Unbound tuning guide][unbound-tuning-guide] and the [Unbound Arch Linux wiki page][unbound-arch-linux] may be of interest.
+
+Some values that are commonly tuned include:
+
+- Increase `rrset-cache-size` and `msg-cache-size` to something much higher than the default `4M`, such as `64M`.
+
+- Increase `discard-timeout` to something like `4800` to wait longer for upstream resolvers, as recursion can take a long time to respond to some domains. Continuwuity default to `dns_timeout = 10` seconds, so dropping requests early would lead to unnecessary retries and/or failures.
+
+### Recursion versus forwarding
+
+Unbound by default employs **recursive resolution** and contacts many servers around the world. While this allows updated and authoritative answers and are generally viable for most users, sometimes these recursive queries can be too slow to fully resolve. As an alternative, you can consider **forwarding** your queries to public resolvers, and benefit from faster responses from their CDNs.
+
+Do note that most popular upstreams (such as Google DNS or Quad9) employ IP ratelimiting, so a generous cache is still needed to avoid making too many queries.
+
+If you want to use forwarders, configure it as follows:
+
+<details>
+
+<summary>unbound.conf</summary>
+
+```
+# Use cloudflare public resolvers as an example
+forward-zone:
+    name: "."
+    forward-addr: 1.0.0.1@53
+    forward-addr: 1.1.1.1@53
+    # Also use IPv6 ones if you're dual-stack
+    # forward-addr: 2606:4700:4700::1001@53
+    # forward-addr: 2606:4700:4700::1111@53
+
+# alternatively, use DNS-over-TLS for forwarders.
+# this will encrypt traffic between you and the forwarder,
+# but takes more time due to TLS overhead.
+# forward-zone:
+    # name: "."
+    # forward-tls-upstream: yes
+    # forward-addr: 1.0.0.1@853#cloudflare-dns.com
+    # forward-addr: 1.1.1.1@853#cloudflare-dns.com
+    # forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com
+    # forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
+```
+
+</details>
+
+[madnuttah-unbound-repo]: https://github.com/madnuttah/unbound-docker/
+[unbound-tuning-guide]: https://unbound.docs.nlnetlabs.nl/en/latest/topics/core/performance.html
+[unbound-arch-linux]: https://wiki.archlinux.org/title/Unbound
+
+## Other resolvers
+
+### dnsproxy
+
+[Dnsproxy][dnsproxy] and its sister product [AdGuard Home][adguard-home] are known to work with Continuwuity and has an official Docker image. They have support for DNS-over-HTTPS as well as DNS-over-QUIC, but not recursion.
+
+To best utilise dnsproxy, you should enable proper caching with `--cache` and set `--cache-size` to something bigger, like `64000000`.
+
+[dnsproxy]: https://github.com/AdguardTeam/dnsproxy
+[adguard-home]: https://github.com/AdguardTeam/AdGuardHome
+
+### dnsmasq
+
+[dnsmasq][arch-linux-dnsmasq] can possibly work with Continuwuity, though it only supports forwarding rather than recursion. Increase the `cache-size` to something like `30000` for better caching performance.
+
+However, `dnsmasq` does not support TCP fallback which can be problematic when receiving large DNS responses such as from large SRV records. If you still want to use dnsmasq, make sure you disable `dns_tcp_fallback` in Continuwuity config.
+
+[arch-linux-dnsmasq]: https://wiki.archlinux.org/title/Dnsmasq
+
+### Technitium DNS
+
+[Technitium DNS Server][technitium] supports recursion as well as a myriad of forwarding protocols, allows saving cache to disk natively, and does work well with Continuwuity. Its out-of-the-box configs however ratelimits single-IP requests by a lot, and hence must be changed.
+
+You may consult this [community guide][technitium-continuwuity] for more details on setting up and fine-tuning a dedicated Technitium instance for Continuwuity.
+
+[technitium]: https://github.com/TechnitiumSoftware/DnsServer
+[technitium-continuwuity]: https://muoi.me/~stratself/articles/technitium-continuwuity/
+
+## Testing
+
+As a rough stress test, you can run `!admin query resolver flush-cache -a` or `!admin server clear-caches` to trigger a netburst of DNS queries. If your resolver can handle these loads without problem, then it should be ready for regular Continuwuity activity.
+
+To test connectivity against a specific server, use `!admin debug ping <SERVER_NAME>` and `!admin debug resolve-true-destination <SERVER_NAME>`.
+
+Note that it is expected that not all servers will be resolved, as some of them may be temporarily offline, have broken DNS and/or discovery configuration, or have been decommissioned.
+
+## Further steps
+
+It is recommended to set **`dns_cache_entries = 0`** inside Continuwuity to fully rely on the external resolver. While Continuwuity does have an internal cache, it can run into reliability issues if you're federating with many domains.
+
+Additionally, you can also make the following improvements:
+
+- Consider employing **persistent cache to disk**, so your resolver can still run without hassle after a restart. Unbound, via [Cache DB module][unbound-cachedb], can use Redis as a storage backend for this feature.
+
+- Consider [enabling **Serve Stale**][unbound-serve-stale] functionality to serve expired data beyond DNS TTLs. Since most Matrix homeservers have static IPs, this should still allow federating with them when upstream resolvers have timed out. For dnsproxy, this corresponds to its [optimistic caching options][dnsproxy-usage].
+
+- If you still experience DNS performance issues, another step could be to **disable DNSSEC** (which is computationally expensive) at a cost of slightly decreased security. On Unbound this is done by commenting out `trust-anchors` config options and removing the `validator` module.
+
+- Some users have reported that setting `query_over_tcp_only = true` in Continuwuity has improved DNS reliability at a slight performance cost due to TCP overhead. Generally this is not needed if your resolver and homeserver is on the same machine.
+
+[unbound-cachedb]: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#cache-db-module-options
+[unbound-serve-stale]: https://wiki.archlinux.org/title/Unbound#Serving_expired_records
+[dnsproxy-usage]: https://github.com/AdguardTeam/dnsproxy#usage
@@ -0,0 +1,135 @@
+# Performance tuning
+
+Continuwuity's default configs are suited for many typical setups and scales appropriately with the size of your hardware. However, there are many scenarios where additional modifications can be made to better utilize your server resources.
+
+This page aims to outline various performance tweaks for Continuwuity and their effects. These adjustments are especially helpful for homeservers that join many large federated rooms or have many users, and it will become increasingly necessary as the Matrix network expands. As always, your mileage may vary according to your setup's specifics. If you have further discussions or recommendations, please share them in the community rooms.
+
+## DNS tuning (recommended)
+
+Please see the dedicated [DNS tuning guide](./dns.mdx).
+
+## Cache capacities
+
+If you have memory to spare, consider increasing the `cache_capacity_modifier` value to a larger number to allow more data to be stored in hot memory. This *significantly* speeds up many intensive operations (such as state resolutions) and decreases CPU usage and disk I/O. Start with a baseline of `cache_capacity_modifier = 2.0` and tune up until you are satisfied with RAM usage.
+
+On the other hand, if your system doesn't have a lot of RAM, consider decreasing the cache capacity modifier to something smaller than `1.0` to avoid low-memory issues (at the cost of higher load on disk/CPU). This recommendation also works if your system has abnormally little RAM compared to the number of CPU cores (for example, 2GB RAM for 12 cores), as cache capacities scale according to number of available cores.
+
+## Disabling some features
+
+You can disable outgoing **typing notifications** and **read markers** to reduce strain on the CPU and network when actively participating in rooms.
+
+```toml
+# disables sending read receipts
+allow_outgoing_read_receipts = false
+# disables sending typing notifications
+allow_outgoing_typing = false
+```
+
+Outgoing presence updates are also considered very expensive and have been disabled by default (`allow_outgoing_presence = false`). For more savings, you may wish to disable _all_ processing of presence entirely.
+
+```toml title=continuwuity.toml
+# disabling presence updates entirely
+allow_local_presence = false
+allow_incoming_presence = false
+allow_outgoing_presence = false
+```
+
+## Tuning database compression
+
+:::warning
+These steps SHOULD be done **before** starting Continuwuity for the first time. While switching database compression midway through is theoretically possible, this has not been tested extensively in the wild.
+:::
+
+### Changing the compression algorithm
+
+For reduced CPU usage at a tradeoff of increased storage space, consider deploying Continuwuity with the faster and less intensive `lz4` algorithm instead of `zstd` for rocksdb, and disable WAL compression entirely:
+
+```toml
+### in continuwuity.toml ###
+rocksdb_compression_algo = "lz4"
+rocksdb_wal_compression = "none"
+```
+
+This tweak can especially be helpful if you have an older or less performant CPU (e.g. a Raspberry Pi) and disk space to spare.
+
+### Increasing bottommost layer compression (`zstd` only)
+
+The bottommost layer of the database usually contains old and read-only data, so it is a suitable place for further compression. In Continuwuity, this is possible by setting `rocksdb_bottommost_compression = true` and tuning `rocksdb_bottommost_compression_level` to a more compact level than the default one used in `rocksdb_compression_level`. This tweak comes at a cost of increased CPU usage, but may prevent your database from growing too large in the long run.
+
+For those using `zstd` compression, the compression level ranges from 1 to 22. An example like this could apply:
+
+```toml
+### in continuwuity.toml ###
+rocksdb_compression_algo = "zstd"
+rocksdb_compression_level = 32767 # magic number, translates to level 3 on zstd
+rocksdb_bottommost_compression = true
+rocksdb_bottommost_compression_level = 9 # level 9 on zstd
+```
+
+For `lz4` users, the default level (`-1`) is already the most compact. You can only further decrease it to favor compression speed over ratio.
+
+Consult these documents for more information on compression tuning and levels:
+
+- [Rocksdb compression documentation][rocksdb-compression]
+- [Rocksdb default compression levels][rocksdb-compression-defaults]
+- [Zstd manual][zstd-manual]
+- [Lz4 manual][lz4-manual]
+
+[rocksdb-compression]: https://github.com/facebook/rocksdb/wiki/Compression
+[rocksdb-compression-defaults]: https://github.com/facebook/rocksdb/blob/main/include/rocksdb/options.h#L208-L217
+[zstd-manual]: https://facebook.github.io/zstd/zstd_manual.html
+[lz4-manual]: https://github.com/lz4/lz4/blob/release/doc/lz4_manual.html
+
+## Other tweaks
+
+### Using UNIX sockets
+
+If your homeserver and reverse proxy live on the same machine, you may wish to expose Continuwuity on a UNIX socket instead of a port. This removes TCP overhead between the two programs.
+
+<details>
+
+<summary>Example config with Caddy</summary>
+
+```toml
+### in continuwuity.toml ###
+
+# `address` and `port` has to be commented out first
+#address = ["127.0.0.1", "::1"]
+#port = 8008
+unix_socket_path = "/run/continuwuity/continuwuity.sock"
+```
+
+```
+### in your Caddyfile ###
+https://matrix.example.com {
+    reverse_proxy unix//run/continuwuity/continuwuity.sock
+
+    # alternatively, use the http2-plaintext protocol
+    # reverse_proxy unix+h2c//run/continuwuity/continuwuity.sock
+}
+```
+
+</details>
+
+### Tuning your trusted servers
+
+:::info Vet your trusted servers!
+Trusted servers are your first point of contact when obtaining public keys from other servers, and they could theoretically impersonate other servers and cause significant harm to your deployment. Please thoroughly verify your trusted servers' credibility before adding them to your configuration.
+:::
+
+Trusted servers are queried sequentially in the order they are listed. If you have multiple trusted servers configured, put the faster ones first:
+
+```toml
+# Example config, using maintainers' recommended homeservers
+trusted_servers = ["codestorm.net","starstruck.systems","unredacted.org","matrix.org"]
+```
+
+Avoid prioritising `matrix.org` as your primary trusted server, as it tends to be quite slow.
+
+Some users have also reported that increasing `trusted_server_batch_size` has helped with faster joins for huge rooms. Start with doubling the default to `2048` until you find a suitable value.
+
+### Enable HTTP/3 on your reverse proxy
+
+Consider enabling the newer **HTTP/3** protocol for inbound connections to Continuwuity. In Caddy HTTP/3 is allowed by default, but you must expose port :443/**udp** on your firewall.
+
+HTTP/3 can vastly improve Client-Server connections especially on unstable networks, as it reduces packet losses and latency from TCP head-of-line blocking, includes workarounds for network switching, and reduces connection establishment handshakes. Continuwuity also includes experimental _outbound_ HTTP/3 support in its Docker images, so connections between Continuwuity servers can benefit from this too.