Planning domains and forwarding ports for multiple protected services
Build a service mapping table that separates hostname quotas from transport-layer forwarding.
Contents of this article
A hostname is not a forwarding rule
Root domains, subdomains and TCP/UDP ports are different resources. Hostnames may share an HTTPS entry while one game needs multiple ports. Confirm domain, port, protocol and IP quotas separately, including any unspecified limits.
Make the mapping usable by another operator
Record service name, public address, listening protocol and port, origin address and port, owner and purpose. Separate production, test and management services instead of exposing administration ports for convenience.
Distinguish protocols even when port numbers match
The same numeric TCP and UDP port does not imply identical forwarding. Validate both separately, including return traffic. Discuss dynamic port ranges and their resource accounting before deployment.
Retire entry points when services are removed
When a service moves or retires, update mappings, DNS and allow rules, then remove unused forwarding. Preserve change records to avoid old ports reaching unintended replacements or consuming quota.
References
NGINX stream proxy documentation