All about domain routers

A domain router holds the per-domain settings: which certificate visitors are shown, whether plain HTTP is redirected to HTTPS, whether the domain serves HTTP/3, and who is allowed to reach it at all. It also decides which server answers requests for the domain.

This article explains where domain routers come from, what each setting controls, and the behaviour worth knowing, including the three settings that work differently on a wildcard domain such as *.example.com.

Domain routers are created automatically

You don't create a domain router by hand. Cyberfusion creates one for you, automatically, in response to whatever owns the domain:

• A virtual host: one domain router for the primary domain, plus one for each server alias.
• A URL redirect: the same pattern, one for the primary domain and one for each server alias.
• An n8n instance.

To change one, open the top-level 'Domain Routers' page and click the domain. Each setting has its own tile.

Finding them

The top-level 'Domain Routers' page lists every domain router across your clusters. Filter by 'Domain', 'Category', 'Force SSL' or 'QUIC'.

The 'Category' tile on the detail page tells you which kind of owner the router belongs to. Each router belongs to exactly one owner.

The settings

'Node'

Default: 'All (load-balanced)' — requests are spread across every node in the cluster running the relevant service, such as nginx or Apache.

Click 'Update' to pin the router to a specific node. Two reasons to pin:

• Cost — when pinned, whatever runs the site's code only needs to be active on that one server, not on every load-balanced one.
• Reserving a node for specific work — see the Admin-node quirk.

If the pinned node is unavailable, traffic fails over to another suitable node automatically.

'Certificate'

The SSL certificate presented for this domain.

Free Let's Encrypt certificates are managed for you via a certificate manager. Paid certificates are attached here once issued.

'Force SSL'

Plain-HTTP requests are redirected to HTTPS.

'QUIC'

Enables HTTP/3 for this domain. HTTP/3 only works over HTTPS.

HTTP/3 is a newer version of HTTP that runs over UDP instead of TCP. Recent Chrome, Firefox, Edge and Safari use it when a site offers it, and fall back to HTTP/2 otherwise.

What visitors notice: pages load faster on unreliable connections such as mobile networks and weak Wi-Fi, because a dropped packet only slows down one file instead of stalling every file the page is loading.

'Security.txt Policy'

Sets which security.txt file is served at /.well-known/security.txt — the file that tells security researchers how to report a vulnerability. See All about security.txt policies.

'Standards Scans'

Opts the domain into automatic, recurring Internet.nl scans, checking TLS, DNSSEC, HSTS, IPv6, security.txt and the modern HTTP security headers. See All about standards scans.

'Firewall Groups'

Restricts who may reach this domain router. Toggle on the firewall groups whose IP networks should be allowed.

No groups toggled on → all IP networks may access it. It becomes an allow-list only once at least one group is selected.

Common use: put staging.client.example on a router with an 'Office IPs' group toggled on. Only your team and the client can reach the staging site, search engines cannot crawl it, and a leaked URL is useless to anyone outside the allow-list. Add both the agency's and the client's office IPs to the group; when an IP changes you update it in one place.

Same pattern for an admin domain: admin.shop.example reachable only from head-office IPs, with the public storefront unrestricted.

Wildcard limitations

On a wildcard domain router such as *.example.com:

The fix for all three: add that exact host as a domain of its own, for example foo.example.com, and set the option there.

Admin-node quirk

A node with the 'Admin' group alongside load-balanced groups such as nginx or Apache is excluded from default routing. It only receives traffic for domain routers where it is explicitly set as the 'Node'.

Why: it keeps one node reserved for lower-priority work, for example serving assets to a CDN, without mixing it into your main HTTP rotation.

To send specific traffic there, pin the relevant domain routers to it. Everything else keeps load-balancing across the regular nodes.