Relay Connection
Some networks cannot accept an incoming connection at all — a router with no way to forward a port, a landlord's network, a mobile hotspot, or an ISP that puts you behind carrier-grade NAT. A relay connection reaches your Media Server on those networks anyway.
Instead of the app connecting to your server, both sides connect to Cardinal. Your Media Server already holds an outbound connection to Cardinal Cloud while Remote Access is on, and the relay sends requests down that connection and streams the responses back:
your app ──▶ Cardinal Cloud ──▶ the connection your server opened ──▶ Media Server
Fig. 1 — a relayed request
Nothing has to be opened, forwarded, or configured, because no part of this is an incoming connection to your network. That is what makes the relay work everywhere, and it is also what makes it a paid feature: every byte crosses Cardinal's servers, and Cardinal pays for that bandwidth.
When the relay is used
The relay is a fallback, not a mode you switch into. Cardinal apps always try a direct connection first — local, then public — and use the relay only when none of those routes answer.
In practice that means the relay carries your traffic when:
- Your router cannot forward the Media Server's port, or the forward is not working.
- Your server has just been enabled and does not have its certificate yet.
- The Direct Connection switch is off in the Remote Access drawer.
- You are on a network that blocks the port outbound from the app's side.
Because it is chosen per connection and not per session, the relay disappears again on its own the moment a direct route becomes available. There is nothing to switch back.
What counts against your allowance
Only relayed traffic is metered. A direct connection never touches Cardinal Cloud and is never counted, no matter how much you stream over it.
Of the relayed traffic:
- Request and response bodies are counted. That is the media itself, and it is the overwhelming majority of what you use.
- Both directions are counted. Uploads to your server and downloads from it both draw on the same allowance.
- Headers are not counted.
Usage accrues per billing period and resets when the period rolls over.
Included bandwidth
| Subscription tier | Relay bandwidth per billing period |
|---|---|
| Free | None — relay unavailable |
| Starter | 35 GB |
| Pro | 100 GB |
| Ultimate | 200 GB |
For a sense of scale, 35 GB is roughly a hundred hours of music, or a handful of movies at high bitrate. Most of it is usually spent on the road: at home, apps take a local connection and spend nothing.
There are two further limits, which exist to stop a runaway stream from consuming a month's allowance in an afternoon:
- A single relayed session is capped at about 10 GB.
- An account can hold 5 relayed sessions open at once.
When the allowance runs out
Relayed requests are refused once the allowance for the period is spent. What that looks like:
- Apps that were relaying stop loading media and report that the connection is unavailable.
- Direct connections keep working, including every app on your own network. Running out of relay bandwidth never locks you out of your own server at home.
- Your Media Server stays connected to Cardinal Cloud, keeps its hostname, and keeps its certificate. Nothing has to be re-enabled.
- Access returns at the start of the next billing period, or immediately if you upgrade your subscription.
The most durable fix is to make a direct connection possible, since direct traffic is unmetered — see Getting the connection through your router.
What the relay is not
It is not a URL you can open in a browser. Every relayed request has to carry your Cardinal account's token, and a browser navigating to an address does not send one. Pasting a relay address into the URL bar returns an authorization error, by design. The Public URL shown in the Remote Access drawer is your direct address, and that one is meant to be opened and bookmarked.
Reaching your server from a browser when no direct connection is possible is what the cloud-hosted apps are for.
It is not as fast as a direct connection. Traffic takes a detour through Cardinal's infrastructure in both directions, which adds latency and caps throughput below what your own connection could do. Everything works; it works less well than the real thing.
Turning the relay off
Direct Connection and Relay Connection have separate switches in the Admin Dashboard, under Cloud Services → the Remote Access card → Configure.
Turning the relay off means your server is reachable remotely only when a direct route exists — apps that cannot find one report the server as unreachable rather than falling back. It also guarantees no relay bandwidth is ever spent, which is the reason most people who turn it off do so.
Was this article helpful?