Configure a custom origin Host using rules-Edge Security Acceleration(ESA)-阿里云帮助中心

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.

Important

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.

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 Rules > Origin Rules.
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 then click the target site in the Website column.
In the navigation pane on the left, choose Rules > Origin Rules. 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 URI and starts with, and then enter http://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-org and rule-virtual-net.

Common origin scenarios

Depending on your origin server type, the default origin Host behavior may not meet your requirements. The following sections describe how to configure the Origin Host and Origin SNI for specific origin types.

Function Compute (FC) origin

If your ESA accelerated domain name differs from the custom domain name bound to your Function Compute (FC) instance, origin requests may fail with a DomainNameNotFound error. To resolve this, create an origin Host rule:

Set the hostname match condition to the ESA accelerated domain name.
Set the Origin Host to the actual custom domain name bound to your FC instance.

This ensures that the FC instance routes incoming requests to the correct function based on the Host header.

GA or WAF CNAME origin

If your origin server is a Global Accelerator (GA) or Web Application Firewall (WAF) CNAME address, and the backend service relies on a specific Host header to identify requests, you must explicitly configure both the Origin Host and Origin SNI in the origin rule. Set both values to the actual domain name bound to the GA or WAF instance—not the ESA accelerated domain name or the CNAME address itself.

OSS origin

ESA supports the following Alibaba Cloud Object Storage Service (OSS) domain types as origin:

OSS public endpoint (external network domain)
OSS transfer acceleration domain

OSS internal network domains are not supported. If you receive a HostForbidden error after enabling ESA, the origin is likely configured with the CNAME record value of an OSS custom domain rather than a valid OSS access domain. Update the origin to the OSS public endpoint or the transfer acceleration domain.

Multi-site or virtual hosting origin

If your origin server hosts multiple websites (for example, using Nginx virtual hosting as shown in the example above), you must manually configure both the Origin Host and Origin SNI to ensure requests are routed to the correct virtual site. If you rely on the default setting (follow the client request Host), ESA nodes may return content from an incorrect site or receive a 404 error.

FAQ

Why does accessing the accelerated domain redirect to another domain or display unexpected content?

This issue can occur for the following reasons:

Origin server redirect

If the browser address bar changes to a different domain after accessing the accelerated domain (for example, from a store URL to an admin URL), the origin server likely has an HTTP-to-HTTPS 301 redirect or an application-level redirect configured. To troubleshoot:

Review and disable unnecessary redirects on the origin server.
In the origin rule, configure the Origin Host and Origin SNI to point to the correct origin domain.

Origin server address configured as a domain name

If the origin server address is configured as a domain name (for example, shop.example.com) rather than an IP address, the origin server may treat incoming requests as direct requests for that domain and trigger a redirect. To resolve this, configure the origin server as a server IP address and use the Origin Host field to specify the corresponding domain name.

Misaligned origin Host and SNI

If the ESA accelerated domain name differs from the domain name expected by the origin server, configure the Origin Host and Origin SNI in the origin rule to match the domain name actually bound to the origin server. After updating the configuration, flush the cache to ensure the changes take effect.

Can I use another ESA accelerated domain or a CDN alias as the origin server?

Circular or nested acceleration is not supported

ESA does not support using another ESA accelerated domain as an origin server. This configuration causes resolution errors or infinite request loops. You must configure the actual origin address behind the accelerated domain, such as an OSS domain name or a server IP address.

Using DCDN or CDN as origin

ESA supports routing origin requests through a DCDN or CDN alias. To prevent double caching, we recommend that you disable caching on the DCDN or CDN side and let ESA handle all caching.

Using Cloudflare R2 as origin

When using Cloudflare R2 as an origin, configure the origin address as the R2 bucket's direct access address (for example, xxx.r2.cloudflarestorage.com) instead of the Cloudflare proxy domain. This avoids double proxying and reduces latency.

Can I enter an IP address in the domain field of an origin rule?

No. The domain field in an origin rule does not accept IP addresses. Web servers such as Nginx use the domain name in the Host header to identify and route requests to the correct virtual site. Entering an IP address in the domain field may cause routing failures.

If you need to route requests to a specific IP address, configure the IP address in the origin server settings and use the Origin Host field to specify the corresponding domain name.

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.

Customize the origin Host