An explanation of backend Port types

Traffic Routing

Traffic to DDoS-protected services is routed through the following configurations. Each can forward traffic to one or more backend addresses.

Use load balancing to define more than one backend.

Add and verify forwarding

1. Open Client Area → Services, then Action → Ports beside the service.
2. Select Single Port and Add port manually (or Add Port when entries already exist). Enter the incoming port and choose the application's Protocol.
3. Choose the backend method and enter the backend address and destination port. For an HTTP/HTTPS virtual host, also enter its Domain. The backend padlock controls encryption between X4B and the backend independently of the incoming protocol.
4. Select Save, reload, and check the protocol, backend address, destination port and domain. Replace the example backend below with your server's reachable address.

The example forwards TCP 8080 to backend port 80, HTTP 8081 to an encrypted backend on 443, and UDP 27015–27020 to the same backend ports. An HTTP incoming port still uses unencrypted HTTP from the client even when backend encryption is enabled.

For a range, select Port Range → Add Port Range, enter the first and last ports, choose the protocol and backend, then save. For all remaining traffic, select DMZ → Add DMZ, choose TCP, UDP or both and the backend, then save. Reload each tab to verify the result. A DMZ is broader than a single port or range; use it only when that scope is required.

Backend Communication Methods

Choose a backend communication method based on your operating system and application requirements. Reverse Proxy is the simplest setup and is recommended for non-technical users.

Tunneled Ports

A tunneled port communicates to the backend over a GRE or IP-in-IP tunnel. This method has the maximum compatibility with UDP services. Tunnels are available on Linux, Windows, BSD and many router operating systems. Automated setup scripts are provided for both Linux and Windows.

Tunneled connections expose the connecting client’s IP directly as the packets from the connecting client are communicated inside the tunnel with minimal modification. Backend servers are able to make outgoing connections over this tunnel (such as to register game servers with list servers).

Tunneled ports come in two varieties:

1. Encapsulated (NAT): Available to all /32 service customers and the default. You will be issued a private network in the 10.x.x.x range to which we will deliver traffic.

2. Routed: Available to Network Protection customers only

To use the tunnel you have defined on the tunnels page and installed on your backend server you will need to have at least one port using the "Encapsulated" or "Routed" port method and referencing the tunnel you wish to use.

Reverse Proxy Ports

A Reverse Proxy (RP) is a type of forwarding that forwards traffic by rewriting the TCP and UDP packets for a new destination. This functions very similarly to our filtering server making a connection to your backend as a client itself. These resources are then returned to the client through our server as though they originated on our server rather than your backend.

This method does not necessarily require changes to your backend or service.

This method is not always compatible with every application and service and does not allow the clients IP address to be retrieved on the backend server (e.g for banning).

At Layer 4 it is not possible for services protected with this method to make outgoing connections as no integration is provided or necessary on the backend server. Modules exist to retrieve the client IP at Layer 7 HTTP(s).

If you can use a GRE/IP-in-IP tunnel, prefer that method.

Port Protocols

The protocol selector in the ports table exposes Layer 4 and Layer 7 options for traffic routing. Layer 7 (lite) are implemented as Layer 7 specific filters at Layer 4.

Layer 4: TCP & UDP

There are two main Layer 4 protocols in use on the internet today and those are TCP and UDP.

TCP

TCP is a stream based protocol with a three way handshake for connection initialization. Being stream based and featuring Layer 4 (protocol) level connection handling it is commonly used for applications requiring client connections.

You may know it from such applications as:

• HTTP and HTTP/2 (see also Layer7 HTTP)
• Minecraft
• TLS/SSL
• SSH

PROXY (v2) header support is available for TCP Reverse Proxy ports. Select "PROXY (v2)" in the backend protocol selection.

UDP

UDP or User Datagram Protocol is a core protocol on the internet popular in real-time and lossy applications such as gaming and media streaming.  UDP Forwarding can be configured on the services Ports page.

Common Uses:

• Domain Name Servers (DNS)

• Online Games

• Video Streaming applications

• Chat servers (but not IRC)

TCP & UDP

A TCP&UDP port type is exposed in the protocol selector. This protocol is functionally equivalent to having both a UDP and TCP port defined with the same settings. This port is provided as a convenience.

Layer 7: HTTP(s) Ports and Games

Unlike TCP and UDP which are OSI Layer 4 Protocols, HTTP is an OSI Layer 7 Port. Multiplexing is supported with other HTTP ports when using the Domain field to define Virtual Hosts. Only HTTP(s) ports are protected against Layer 7 HTTP attacks.

HTTP servers typically run on TCP port 80; HTTPS (SSL/TLS) servers typically run on port 443. Frontend and backend encryption are configured separately:

Use the padlock icon next to the backend server IP and port to enable HTTPS for backend communication. Selecting HTTPS for the frontend does not select the backend protocol.

Both HTTP and HTTPS ports can be defined, but multiplexing cannot occur between HTTP and HTTPS ports. See HTTPS and SSL configuration.

When using the domain field you must specify either:

1. an exactly matching host (e.g domain.com, www.domain.com or sub.domain.com); or
2. a wildcard (e.g *.domain.com); or
3. .domain.com which matches both domain.com and *.domain.com

See HTTP protocol support and Layer 7 protection modes for more information.

HTTP Redirect Backend

A special backend type is available for HTTP(s) ports known as Redirect. This backend type allows you to define a URL to which all traffic to this port will be redirected. This is useful for redirecting HTTP traffic to HTTPS or redirecting traffic to another domain.

This backend type is implemented with the same features as a standard HTTP(s) port with a redirection HTTP Zone. As such the same variables are available for use in the redirect URL such as $scheme, $host, $uri, $request_uri. The default REDIR target is https://$host$request_uri, which preserves the original path and query string. For example, http://example.com/search?q=test redirects to https://example.com/search?q=test. Here $uri is the normalized path without query parameters; a custom target of https://$host$uri discards them. Use $request_uri for an HTTP-to-HTTPS redirect that preserves the complete request URI.

Game and voice servers

Game-specific Layer 7 protection checks the application's protocol to filter attacks such as connection or server-query floods. Select the matching protocol in the ports table:

For A2S, use the A2S type on the game's UDP query port and forward any required TCP service separately. The FiveM profile is available on Anycast services and uses matching TCP and UDP port numbers. Its website or HTTP resources can also use HTTP Layer 7 protection; see the FiveM setup guide.

Other games benefit from Layer 4 and dynamic mitigation using their normal TCP/UDP ports. Choose a game-specific mode when it matches the service you run. See Layer 7 protection modes for the protocol requirements and adjusting mitigation for tuning.