Configure an origin server

更新时间:
复制 MD 格式

DCDN supports OSS, IP-based, and domain name-based origin servers. You can configure multiple origin addresses for each type and set priority and weight to enable load balancing and failover.

Before you begin

  • You are responsible for any data transfer or bandwidth costs incurred by the origin server during origin fetch. For example, you are charged for traffic and bandwidth from your own data center, or for data transfer fees from an OSS bucket.

  • DCDN supports failover between primary and secondary origin servers. When multiple origin servers are configured, DCDN first attempts an origin fetch from the server with Priority set to Primary. If the primary origin server fails three consecutive health checks, DCDN fails over to a server with Priority set to Secondary. If the primary origin server passes a subsequent health check, DCDN marks it as available and restores its primary status. If all origin servers have the same priority, DCDN uses round-robin scheduling for origin fetches.

    Note

    Health checks: DCDN performs active Layer 4 health checks by probing port 80, port 443, or any custom ports you have configured on the origin server. DCDN sends probes every 2.5 seconds and marks an origin server as unavailable after three consecutive failed probes.

Add or modify an origin server

  1. Log on to the DCDN console.

  2. In the left-side navigation pane, click Domain Names.

  3. On the Domain Names page, find the domain name that you want to manage and click Configure in the Actions column.

  4. On the Basic Settings tab, find the Origin Information section.

  5. In the Origin Information section, add a new origin server or modify an existing one.

    • To add an origin server, click Add Origin Server.

    • To modify an existing origin server, find it in the list and click Modify in the Actions column.

    源站配置

    Parameter

    Description

    Type

    Select the origin server type and enter its address (up to 67 characters). You can add up to 20 origin servers per domain name.

    • OSS Domain

      • If you use an Object Storage Service (OSS) bucket as the origin server, you can enter the public domain name of the OSS bucket, such as ***.oss-cn-hangzhou.aliyundoc.com.

      • You can obtain the public domain name of an OSS bucket in the OSS console. You can also select the domain name of an OSS bucket that belongs to the current Alibaba Cloud account from the Domain Name drop-down list.

    • IP: You can configure one or more IP addresses for an origin server. Internal IP addresses are not supported. IPv4 addresses and IPv6 addresses are supported. At least one of the IP addresses must be an IPv4 address. If you use a public IP address of an Alibaba Cloud Elastic Compute Service (ECS) instance as the address of the origin server, the IP address is exempt from manual review. You need to obtain the permissions to configure origin fetch over IPv6 in advance. Otherwise, updates to settings about IPv6 will be ineffective. For more information, see Configure origin fetch over IPv6.

    • Origin Domain: You can configure one or more origin domain names.

      Configuration rules for origin domains (click to expand rule details)

      • The origin domain cannot be the same as the accelerated domain name. Otherwise, a back-to-origin error occurs due to loop resolution.

      • The format of the origin domain name:

        • The domain name must be 1 to 67 characters in length,

        • and can contain lowercase letters, digits, and hyphens (-). Example: example.com.

        • The domain name cannot contain Chinese characters, uppercase letters, or special characters other than hyphens (-). The domain name cannot be only a hyphen (-). A hyphen (-) in a domain name cannot be followed by another hyphen (-). The domain name cannot start or end with a hyphen (-). If the domain name contains Chinese characters, such as 阿里云.网址, you must apply for an ICP number for the domain name in Chinese characters and use the Punycode tool to convert the Chinese characters into English letters, such as xn--fiq****.xn--eq****. Then, you can specify the converted domain name as the domain name that you want to accelerate.

      • You can add the domain name of an Alibaba Cloud Application Load Balancer (ALB) instance, such as example.hangzhou.alb.aliyuncs.com, as the address of an origin server.

    Priority

    You can configure primary and secondary origins. Primary origins have higher priority than secondary origins. When a user request triggers an origin fetch, Alibaba Cloud DCDN first tries the primary origin. If the primary origin fails (TCP connection between CDN node and origin fails), it falls back to the secondary origin. Priority values range from 0 to 127—the lower the number, the higher the priority. The default priority for a primary origin is 20; for a secondary origin, it is 30. To use other values, submit a ticket.

    For example, if you have two origins, A and B, with origin A set as primary and origin B as backup, user requests that perform an origin fetch through Alibaba Cloud DCDN will be directed to origin A first. If origin A fails (the TCP connection between the CDN node and the origin fails), the request will be redirected to origin B. When origin A recovers, traffic will switch back from origin B to origin A.

    Weight

    When multiple origins share the same priority, Alibaba Cloud DCDN distributes user requests across origins proportionally based on their weights, enabling weighted load balancing. Set weights according to your business needs.

    • Range: 1–100. Higher values mean a larger share of requests.

    • Default value: 10.

    Example: Origins A and B both have primary priority. A has weight 80; B has weight 20. Requests are distributed in an 8:2 ratio between A and B.

    Note
    • Weight-based routing applies only to static content by default. To apply it to dynamic content, enable dynamic load balancing. Configure back-to-origin routing to retrieve dynamic content.

    • The actual request distribution may not match configured weights in some cases:

      • Low back-to-origin QPS (for example, less than 10 QPS) can cause uneven distribution.

      • If requests come from one or a few IP addresses, DCDN routes them to the same node and may direct most requests to one origin server due to persistent TCP connections.

      To verify weight distribution, use a third-party monitoring tool with probe clients across diverse locations and ISPs.

    Port

    Select a port that your origin server supports.

    • Port 80: DCDN retrieves content from the origin server through port 80.

    • Port 443: DCDN retrieves content from the origin server through port 443. The origin server must support HTTPS.

    Note

    DCDN supports only ports 80 and 443 by default. To use a custom port, submit a ticket.

  6. Click OK.

Origin server status

DCDN automatically probes your origin servers and displays a health status to help you identify issues quickly. DCDN nodes check connectivity by establishing TCP connections and consider a failed connection an anomaly. After configuring an origin server, you can view its Origin Server Status in the origin server list.

image.png

The following table describes each status.

Status

Description

Healthy

No issues detected. An IP-based origin with multiple ports is considered healthy if at least one port is reachable. A domain name-based origin is considered healthy if more than 80% of its resolved IP addresses are reachable.

Partially Healthy

Some issues may be present. The health score is below 80%. Check whether your origin server is operating normally.

Abnormal

The origin server is at high risk. The health score is below 20%. Inspect your origin server and online services immediately.

Unknown

The origin server was recently added or modified, and no probe data is available yet. You can wait a few minutes and then refresh the page.

Note

The health status is for reference only and may occasionally be incorrect. Rely on your service's actual performance for final verification.

Origin fetch retry, origin fetch timeout, and origin probing

  • Origin fetch retry order:

    • Retries are attempted on origin servers in order of their priority, from highest to lowest.

    • If multiple origin servers share the same priority, retries are distributed according to their configured weights.

  • Origin fetch retry granularity:

    • Retries are performed at the IP address level. If an origin server is specified by a domain name, the system attempts to connect to all IP addresses resolved from that domain name. Another available origin server is tried only after connections to all IP addresses for the current origin server have failed.

    • During a retry attempt, the system automatically skips any origin server IP addresses listed in the dead table.

  • Origin fetch retry status codes:

    • A or DCDN node triggers an origin fetch retry when it receives a 5xx status code from the origin server.

  • Origin fetch timeout: If an origin server actively responds with a retry-triggering status code, the or DCDN node immediately retries the request. If no such status code is returned from the origin server, the request follows the origin fetch timeout logic, and the or DCDN node triggers a retry only after the timeout period is reached.

    • Origin server TCP connection timeout: 10 seconds.

    • Origin server write timeout: 30 seconds by default (timeout for writing content to the origin server after a connection is established).

    • Origin read timeout: The default is 30 seconds. This timeout occurs if the origin server, after establishing a connection, fails to send a complete response for the content requested by the DCDN node within this period.

    • You can adjust both the origin server write and read timeouts by configuring the origin fetch HTTP request timeout.

  • Origin probing logic:

    • TCP connection failures: If a or DCDN node fails to establish a TCP connection with an origin server's IP address twice in a row (due to a connection failure or timeout), or DCDN removes the IP address from the list of available origin servers and adds it to a dead table. Subsequent origin fetch requests are not sent to this IP address. The or DCDN node then probes the IP address every 5 seconds by attempting a TCP connection. If the connection succeeds, the IP address is restored to the list of available origin servers.

    • TCP connection is normal: If a DCDN node has a normal TCP connection to an origin server IP address but receives a retry status code (such as 5xx) from the origin server, the retry logic is triggered. However, the origin server IP address remains in the list of available origin server addresses, and subsequent requests are still sent to the origin server based on its weight. (This means that if the Layer 4 TCP connection is normal, a Layer 7 HTTP request exception will not actively block the origin server IP address. If you need to actively block the origin server IP address when a Layer 7 HTTP request exception occurs, you must submit a ticket to request the configuration).

Related documents