Customize the origin Host
When Edge Security Acceleration (ESA) requests resources from an origin server, the default Host request header is determined by the origin server type. When needed, you can modify the origin Host request header to ensure that requests are correctly routed to the origin server.
Your origin server must support matching different virtual sites using the Host request header. Otherwise, this feature does not work as expected.
An origin Host parameter set in an origin rule has a higher priority than one set in Manage DNS Records. If the parameter is configured in both locations, the value from the origin rule is used.
Related concepts
Default ESA origin Host
The Host request header specifies the domain name of the requested server. When an ESA point of presence (POP) requests resources from an origin server, the default Host is determined by the following rules:
If the Record Value is an IPv4 address, IPv6 address, domain name, Server Load Balancer, or origin pool: The default setting for Origin Host is Match Requested Domain Name. This means the Host from the client request is used as the origin Host.
If the Record Value is OSS/S3 Compatible: The default setting for Origin Host is Match Origin's Domain Name. This means the domain name of the origin server is used as the origin Host.
The origin server uses the Host field in the origin request to return resources for the corresponding site, such as www.example.com. If you have multiple sites configured on your origin server (for example, in a virtual hosting scenario), the origin server validates the Host field to return the correct resources.
Virtual hosting
Virtual hosting is a technique that allows a single web server to host multiple websites. The server uses different domain names or hostnames to distinguish between the websites. When a client requests a specific domain name or hostname, the server directs the request to the corresponding virtual site to deliver the correct content.
Troubleshoot origin 404 errors
If HTTPS requests return a 404 error after you connect your site to ESA, use the following steps to check your origin server configuration.
1. Determine whether the issue is on the origin server
Add a local hosts entry that maps your origin server domain name to the origin server IP address, and then send an HTTPS request directly to the origin server, bypassing ESA. If the origin server also returns a 404 error, the issue is on the origin server rather than ESA.
2. Check the nginx server_name directive
Verify that the server_name directive in your nginx configuration file matches the Origin Host configured in the ESA console. If server_name does not match the origin Host, the origin server returns a 404 error.
3. Check the origin Host setting
On the Origin Rules page in the ESA console, verify that Origin Host is set to a domain name, not an IP address. If Origin Host is set to an IP address, the server_name directive on the origin server cannot match it, and the origin server returns a 404 error.
A connection failure (for example, a 521 or 522 error) caused by removing the SSL listener on the origin server is out of scope for this troubleshooting section. For that scenario, see the ESA 521 and 522 error troubleshooting documentation.
Create an origin Host rule
In the ESA console, select Websites, and then click the target site in the Website column.
In the navigation pane on the left, choose .
Click Create Rule and enter a Rule Name.
In the If requests match... section, configure the conditions for the request. For more information about how to configure rules, see Components of a rule expression.
In the Origin Host section, click Configure. Specify the origin Host and click OK.
Example: Configure virtual sites
This example shows how to configure virtual sites using Nginx. In the Nginx configuration file, you can set up multiple virtual sites in the server blocks, such as www.example.org, www.example.net, and www.example.com.
server {
listen 80;
server_name example.org www.example.org;
...
}
server {
listen 80;
server_name example.net www.example.net;
...
}
server {
listen 80;
server_name example.com www.example.com;
...
}Nginx first checks the Host field in the HTTP request header to determine which virtual site to route the request to. If no match is found, Nginx uses the default virtual site. If no default site is configured, the first server block is used as the default. To correctly route each request to its corresponding virtual site, follow these steps:
In the ESA console, select Websites, and in the Website column, click the target site.
In the navigation pane on the left, choose . On the Origin Rules page, click Create Rule.
On the configuration page, configure the parameters and click OK:
Rule Name: Enter a name for the rule, such as
rule-virtual-com.If requests match...: Configure the rule conditions. For example, select
Full URIandstarts with, and then enterhttp://www.example.com.Then execute...: In the Origin Host section, click Configure and enter the corresponding virtual site address, such as
www.example.com
Repeat the previous step to create two more rules:
rule-virtual-organdrule-virtual-net.
FAQ
How do I verify that origin configuration changes have taken effect and troubleshoot origin function issues?
Verify origin IP or configuration changes
After updating the origin configuration, access your website and verify that the returned content is from the new origin server. You can also check the access logs on the origin server to confirm that requests are arriving from ESA nodes.
Troubleshoot origin feature failures (for example, language switching)
If a site feature (such as language switching) stops working after enabling ESA, follow these steps:
Add a local hosts entry that maps the origin server IP address to the test domain. Access the site through this direct connection, bypassing ESA, to determine whether the issue originates from the origin server itself.
Clear the browser cache and retry.
Related documentation
Rule-related features vary in effective priority, reentrancy, and effective granularity. For details, see Characteristics of rule-based features.