Can I route based on the Host Header?

Short answer

Yes. If each domain name is to be a separate vService, Virtual Hosting is used on the HTTP vServices that share the same IP and port. To route within a single vService, an HTTP Header condition (Header Name: Request, Host; Case Insensitive) is created and bound to a Conditional Backend Services block. On an L7 TCP vService where TLS is not terminated, the SSL SNI Info condition is used, and to send the user to another domain name, the Location Redirection action is used.

Problem: Multiple Domain Names Share the Same IP

Multiple websites are published from a single public IP address; which site is requested is understood from the Host header in the HTTP request (in HTTPS, also from the SNI value in the TLS handshake). The requests need to be sent to the right Backend Services based on the domain name; otherwise all domain names end up at the same application.

Solution: Five Methods

Method 1 splits the domain names into separate vServices; Methods 2–4 select a Backend Service within a single vService; Method 5 does not select a server, it redirects the client to another address.

Your situation	Suitable method
Each domain name should be a separate vService with its own certificate, WAF and log settings	Method 1: Virtual hosting
I want to send requests to different Backend Services based on the domain name within a single HTTP vService	Method 2: HTTP header (Host) condition
I want to set up domain-based routing from the command line	Method 3: URL condition with WEB-CLI
TLS is not decrypted on TR7 (SSL passthrough, L7 TCP)	Method 4: SSL SNI Info condition
I want to send the user to another domain name	Method 5: Location redirection

Method 1: Virtual Hosting Recommended

• How it works Each vService that shares the same IP and port defines its own domain names; the request goes to the relevant vService based on the Host (in HTTPS, SNI) value.
• Where it is opened vService form → Virtual Hosting
• Requirement A domain name list on all the vServices that share the same IP:port; while there is a domain name in the list, the HTTP/3 (QUIC) protocols cannot be used
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the vService edit form

The Load Balancer → Load Balancer vService List steps are followed and the HTTP vService that will handle one of the domain names is opened (the same form is also used when a new vService is created).

2

Adım 2 Enable Virtual hosting

The Virtual Hosting switch is set to Enabled; the first domain name row opens.

3

Adım 3 Enter the domain names

The domain names this vService will handle are entered row by row and in lowercase (e.g. www.example.com; matching is case-sensitive, and the domain name is saved as it is entered); a wildcard can be used (*.example.com, it also matches multiple subdomain levels). If more than one definition fits the same value (e.g. a.example.com and *.example.com), the most specific definition does not take precedence; defining the same domain name in more than one vService is avoided.

4

Adım 4 Save

The Save button is clicked.

5

Adım 5 Configure the other vServices the same way

Steps 1–4 are repeated for each vService that will share the same IP:port. A vService with an empty list cannot be defined on the same IP:port; the frontends of the sharing vServices must be in the same encryption class (encrypted: HTTP/1.1, HTTP/2; unencrypted: HTTP, HTTP → HTTPS).

Verification

1RoutingClient side

A request is sent to the shared IP for each domain name. HTTP requests that match the list of no vService get a 503; in HTTPS, if the SNI does not match, the connection is closed.

Commandcurl -s -H "Host: www.example.com" http://203.0.113.10/

ExpectedEach domain name gets a response from its own vService

Method 2: HTTP Header (Host) Condition

• How it works Within a single vService, a Conditional Backend Services block is selected based on the Host header; requests that do not match go to Default Backend Services.
• Where it is openedLoad Balancer → Conditions · vService form → + Conditional backend services
• Requirement The target servers being defined as Backend Services
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Prepare the target Backend Services (if needed)

If the servers of the domain names are not yet defined as Backend Services in TR7, they are added first; if they are defined, this step is skipped. With Load Balancer → Backend Services → Add, the Backend Service Name and Address are entered for each server and a Health Check profile is selected. Details: How is a Backend Service added; which information is required?

2

Adım 2 Open the condition form

The Load Balancer → Conditions → Add steps are followed; the form is described in the Conditions · How to Add? section.

3

Adım 3 Define the Host condition

The Condition Name is entered. Criteria = HTTP header; Request in the selector to the left of the Header Name field and Host in the field are left as they are (the form opens with these values). The matching method Exact match (default), Case Insensitive checked, and Query = www.example.com are entered. For multiple subdomains, matching End and Query .example.com can be used.

4

Adım 4 Save the condition

The Add button is clicked. If a separate condition is needed for each domain name, steps 2–4 are repeated.

5

Adım 5 Open the vService edit form

The Load Balancer → Load Balancer vService List steps are followed and the HTTP vService is opened.

6

Adım 6 Add a conditional block

The + Conditional backend services button in the Default Backend Services table is clicked (Conditional Backend Services).

7

Adım 7 Select the condition and the target

In the Select Conditions field of the block, the Host condition is selected, and in the Backend Service selector, the Backend Services of that domain name are selected. A separate block is added for each domain name; Default Backend Services handles the domain names that do not match.

8

Adım 8 Save

The Save button is clicked.

Verification

1RoutingTR7 side

On the Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking → HTTP Logs screen, the Host value of the request and the Backend Service that responded to the request are compared (Viewing HTTP Logs). For records, the LOG field must be on in the vService.

ExpectedHost: www.example.com → Backend Service of the block

2Request testClient side

Requests are sent with different Host values.

Commandcurl -s -H "Host: www.example.com" http://203.0.113.10/

ExpectedEach Host gets a response from its own Backend Service

Method 3: URL Condition with WEB-CLI

• How it works The domain name is caught with the URL condition, which evaluates the full URL (scheme + host + path + query), and is bound to the conditional block from the command line.
• Where it is opened TR7 WEB-CLI → lb condition · lb service
• Requirement WEB-CLI access; the target Backend Services being defined
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Add the URL condition

lb condition add criteria url query '^https?://www\.example\.com(:[0-9]+)?/' --content_placement regex --caseInsensitive true --name www-host

The URL value has the http(s)://host[:port]/path?query format (URL structure); the regular expression catches only the www.example.com host, together with the port if a non-standard port is written.

2

Adım 2 Get the condition ID

lb condition list

The ID of the condition (the value starting with lbConditions-) is taken from the output; the block recognizes the condition by this ID, not by its name.

3

Adım 3 See the existing blocks

lb service show <vService>

The number of blocks in the dynamicBackendList list is seen; for the new block, the first empty index is used (0 if there are no blocks). If an occupied index is written, the block at that index is replaced.

4

Adım 4 Add the block

For the case where the vService has no conditional block yet (index 0):

lb service update id <vService> --dynamicBackendList.0.cond "<condition-id>" --dynamicBackendList.0.beList.0 <backend-service>

In place of <backend-service>, the name of the Backend Service or of the Backend Group is written.

Verification

1Block recordTR7 side

The vService is displayed again; the routing is checked with the verification cards of Method 2.

Commandlb service show <vService>

ExpectedNew block in dynamicBackendList

Method 4: SSL SNI Info Condition

• How it works Without TLS being decrypted on TR7, the block is selected based on the SNI value in the TLS handshake.
• Where it is openedLoad Balancer → Conditions · L7 TCP vService form → + Conditional backend services
• Requirement An L7 TCP vService whose frontend protocol is TCP (SSL passthrough)
• vService type L7 TCP

Step-by-Step Configuration

1

Adım 1 Prepare the target Backend Services (if needed)

If the servers of each domain name are not defined as Backend Services, they are added as in step 1 of Method 2.

2

Adım 2 Open the condition form

The Load Balancer → Conditions → Add steps are followed.

3

Adım 3 Define the SNI condition

Criteria = SSL SNI info is selected and the domain name (e.g. mail.example.com) is entered in the Query field. The match is exact text and case-insensitive; a wildcard and multiple domain names cannot be entered, a separate condition is defined for each domain name.

4

Adım 4 Save the condition

The Add button is clicked.

5

Adım 5 Open the L7 TCP vService edit form

The Load Balancer → Load Balancer vService List steps are followed and the L7 TCP vService whose frontend protocol is TCP is opened.

6

Adım 6 Add a conditional block

The + Conditional backend services button in the Default Backend Services table is clicked (L7 TCP · Conditional Backend Services).

7

Adım 7 Select the condition and the target

In the Select Conditions field of the block, the SNI condition is selected, and in the Backend Service selector, the Backend Services of that domain name are selected.

8

Adım 8 Save

The Save button is clicked. On a vService where an SNI condition is used, TR7 inspects the first packets of the connection to read the SNI; on connections where no TLS handshake arrives, acceptance can be delayed by up to 10 seconds.

Verification

1RoutingClient side

Each domain name is sent as the SNI value, and which server the returned certificate belongs to is checked.

Commandopenssl s_client -connect 203.0.113.10:443 -servername mail.example.com

ExpectedEach domain name returns the certificate of its own Backend Service

Method 5: Location Redirection

• How it works A request that matches the condition is redirected to another domain name with a 3xx; this is not a server selection, the client sends a new request to the new address. Details: How do I redirect a specific URL to another URL with a 301/302?
• Where it is openedLoad Balancer → Actions · vService form → Details → Actions
• Requirement A condition (if Location redirection is saved without a condition, it never runs)
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Prepare the condition

If there is no Host condition that defines the domain name to be redirected, it is created with steps 2–4 of Method 2.

2

Adım 2 Open the action form

The Load Balancer → Actions → Add steps are followed.

3

Adım 3 Define Location redirection

Action Type = Location redirection is selected; the target address (e.g. https://www.example.com) is entered in the Redirect Location field, the redirect code (e.g. 301) in the Redirect Code field, and the Host condition is selected in the Conditions field.

4

Adım 4 Save the action

The Add button is clicked.

5

Adım 5 Open the Details panel of the vService

The Load Balancer → Load Balancer vService List steps are followed, the vService is opened and the Details button at the top of the form is clicked.

6

Adım 6 Add the action to the vService

The created action is selected in the Actions field.

7

Adım 7 Save

The Save button is clicked.

Verification

1RedirectClient side

A request is sent with the domain name to be redirected and the response headers are checked.

Commandcurl -sI -H "Host: example.com" http://203.0.113.10/

ExpectedHTTP/1.1 301 · Location: https://www.example.com

Common Mistakes

• Forgetting that Host includes the port on non-standard ports. On ports such as 8443, the client sends Host: site.com:8443; Exact match site.com does not match it. In this case, matching Start with site.com: or Regex is used.
• Not checking Case insensitive. Clients can send the domain name in upper case.
• Using an SNI condition on a vService where TLS is decrypted on TR7. The SSL SNI Info condition has a value only in traffic where TLS is not decrypted (passthrough); on an HTTP vService where TLS is terminated, a Host condition or Virtual Hosting is used, and on an L7 TCP vService where TLS is terminated (TCP + TLS), Dynamic Condition with the SNI Received from Client variable is used.
• Enabling Virtual hosting on only one vService. A domain name list must be defined on all the vServices that share the same IP:port.
• Binding the condition by its name in WEB-CLI. --dynamicBackendList.N.cond expects the condition ID.

How it is done in the documentation

• HTTP (L7) vService · Virtual Hosting
• HTTP Header · Header Name
• URL · URL Structure
• SSL SNI Info · Scenario 1: SNI-Based Routing in SSL Passthrough

Related questions

• Can I define more than one vService on the same IP:port?
• How do I route to different servers based on the URL path (e.g. /api → API servers)?
• With passthrough, can I route to different backends based on SNI?