Skip to content

All about domain routers

A domain router decides what happens to incoming HTTP requests for a specific domain — which node serves them, which certificate is presented, whether HTTPS is forced, and who's allowed to reach the domain at all.

This article explains where domain routers come from, what each setting controls, and the routing behaviour worth knowing.

Where to find domain routers

In Core, the top-level 'Domain Routers' page lists every domain router across your clusters. Filter by 'Domain', 'Category', 'Force SSL', or 'QUIC' to narrow the list.

Click a domain to open its detail page — each setting has its own tile or section there.

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 — same pattern: one for the primary domain, one for each server alias.
  • An n8n instance.

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

Per-router settings

Node

By default, the 'Node' tile shows 'All (load-balanced)' — Cyberfusion spreads requests across every node in the cluster that runs the relevant service (nginx, Apache, etc.).

Click 'Update' on the tile to pin the domain router to a specific node. Two common reasons to pin:

  • Cost — when pinned, the backing resources (FPM pool, Passenger app, etc.) only need to be active on that one node, not on every load-balanced node.
  • Reserve a specific node for specific work — see the Admin-node quirk below.

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

Certificate

The 'Certificate' tile attaches 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.

Security.txt Policy

The 'Security.txt Policy' tile sets which security.txt file is served for this domain — the file at /.well-known/security.txt that tells security researchers how to report a vulnerability. See All about security.txt policies.

Not served on wildcard domain routers

For a wildcard domain router (e.g. *.example.com), the security.txt file isn't served — visitors to https://anything.example.com/.well-known/security.txt get a 404, even when a policy is attached.

To publish security.txt on a sub-host covered by the wildcard, add a literal domain router for that exact host (e.g. foo.example.com) and attach the policy there.

Force SSL

When 'Force SSL' is enabled, plain-HTTP requests are redirected to HTTPS. Toggle from the tile.

Always on for wildcard domain routers

For a wildcard domain router (e.g. *.example.com), the toggle has no effect when turned off — plain-HTTP requests for any sub-host covered by the wildcard are still redirected to HTTPS.

If you need plain HTTP to keep working for one specific sub-host, add a literal domain router for that exact host (e.g. foo.example.com) and turn Force SSL off there.

QUIC

'QUIC' enables HTTP/3 for this domain. Toggle from the tile.

HTTP/3 is a newer version of HTTP that runs over UDP instead of TCP. Recent versions of Chrome, Firefox, Edge, and Safari use HTTP/3 when a site offers it, and fall back to HTTP/2 otherwise. The main visible effect is that pages load faster on unreliable connections — mobile networks, weak Wi-Fi — because a dropped packet only slows down one file, instead of stalling every file the page is loading.

HTTP/3 only works over HTTPS.

No effect for wildcard domain routers

For a wildcard domain router (e.g. *.example.com), the toggle has no effect. Requests for sub-hosts covered by the wildcard use HTTP/2 even when 'QUIC' is turned on. To use HTTP/3 for a specific sub-host, add a literal domain router for that exact host and enable 'QUIC' there.

Standards Scans

The 'Standards Scans' tile 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

The 'Firewall Groups' section restricts who may reach this domain router. Toggle on the firewall groups whose IP networks should be allowed.

If no groups are toggled on, all IP networks may access the domain router. The section behaves as an allow-list only once at least one group is selected.

Lock down a staging domain

A common use case for web agencies: put staging.client.example on a domain router with a 'Office IPs' firewall group toggled on. Only your team and the client can reach the staging site — search engines can't crawl it, and a leaked URL is useless to anyone outside the allow-list. Add the agency's office IPs and the client's office IPs to the group; when an IP changes, update it in one place.

For shops and SaaS the same pattern works for an admin domain — admin.shop.example reachable only from head-office IPs, the public storefront unrestricted.

Admin-node quirk

If a node has the 'Admin' group alongside load-balanced groups (such as nginx or Apache), it's excluded from default routing. That node only receives traffic for domain routers where it's explicitly set as the 'Node'.

The use case: keep one node reserved for lower-priority work — serving assets to a CDN, for example — without it being mixed into your main HTTP rotation. To direct specific traffic to that Admin node, pin the relevant domain routers to it; everything else continues to load-balance across the regular nodes.