Measurement server requirements: the reasoning behind the thresholds
The question we hear most often on server applications is not the list of conditions but the reasoning behind them: "We have a 10 Gbps card but the line is shared — why doesn't that work?" or "The IP is static, why is a domain name required?"
Every threshold serves one purpose: what gets measured should be the line itself, not the server's limit. A speed-test server must always be distinctly faster than the user's connection; otherwise the measurement reports the server's ceiling rather than the user's line.
Network
At least 1 Gbps dedicated. The critical word is "dedicated". Speed-test traffic is bursty rather than steady: a measurement fills the line for a few seconds, then goes quiet. On a shared or metered line that burst collides with neighbouring traffic, and the result tells you about that moment's neighbours rather than about the user's line.
No traffic shaping. If test traffic is rate-limited, prioritised or filtered, the measurement is distorted directly. This is the most common reason for rejection during review — and often the server owner is unaware of it, because the shaping sits one layer up in the rule set.
24/7 reachability. Health checks run continuously. It is worth stressing this: a server running is not proof that it is reachable. The process may be up while the firewall drops inbound packets. That is why the check is made from the outside, not from within.
Ports. In the default install the test port is 443 TCP and UDP — HTTP/3 is used alongside TLS. Forgetting to open UDP is the most frequent post-installation snag.
IPv6 is not mandatory but recommended. It counts as a positive signal in server selection.
A domain name, not a bare IP
Registration is bound to a fully qualified domain name (for example
hiztesti.company.com), not to an IP; a bare address is not accepted. Two
practical consequences:
- When the server's IP changes, updating the DNS record is enough — your record in the network is untouched.
- Test traffic is carried over HTTPS only, and the certificate is issued for the domain name.
You do not have to supply the certificate yourself: during installation NETMETRİK Server obtains a free certificate from Let's Encrypt and renews it automatically before expiry. Pointing to your own certificate, or running behind a reverse proxy (nginx, Caddy, Cloudflare) that terminates TLS, is also supported — the installer detects the reverse proxy on its own.
Hardware and the clock
The recommendation is at least a 2-core CPU and 8 GB of memory; on lines of 10 Gbps and above, more cores and up-to-date NIC drivers are needed. The profile you declare in the application is compared against the inventory the server reports after installation — which is why an accurate declaration makes your life easier.
One item that is easily overlooked: the system clock must be NTP-synchronised. Latency and jitter are computed from timestamps; a drifting clock writes a deviation into the measurement that has nothing to do with the network.
Operating system
Linux x86_64 / aarch64 (a current Ubuntu LTS or Debian is recommended), macOS and FreeBSD (x86_64) are supported. The install script leaves a systemd unit behind; on distributions without systemd you take on process management yourself.
Organisational conditions
Three more items apply to the public network: a corporate website with a valid organisation name and contact details (the sponsor link on the result card points there), an accurately declared real location for the server (nearest-server selection depends on it), and the rule that one organisation may not hold more than one public-network server in the same city — the geographic diversity rule. HIZTESTI Custom servers that only serve your own widgets are exempt.
Am I a borderline case?
The full list and tables live in the server requirements document. If you meet the conditions, continue with the quick start; if you are a borderline case, write to us — we would rather assess a sub-1 Gbps line or an unusual topology together.
