Most origin problems appear immediately after you activate on staging, and nearly all of them trace back to a mismatch between a Delivery Manager setting and your origin's own configuration.

Test on the staging network first. Staging reproduces these failures without exposing them to end users.

Identify source of the problem

Two checks separate an origin problem from a delivery problem.

1. Request the origin directly. Bypass Akamai and request your content using the origin hostname, over the same scheme and port edge servers use. If the direct request also fails, the problem is on your origin and no Delivery Manager setting will fix it.
2. Send the host header Akamai sends. If the direct request succeeds only when the Host header matches your public domain, the forward host header setting is the likely cause.

curl -sv https://1hkeh1g76-www.example.com/picture.jpg \
  -H "Host: www.example.com"

Compare the result to the same request without the -H override. A difference between the two points at the host header.

The origin can't be reached

Edge servers can't resolve the origin hostname

Your origin hostname must resolve from the public internet, through a public DNS server. A record that only exists on your internal resolvers works from your office and nowhere else.

Verify from outside your own network with dig or nslookup, or an external DNS lookup service.

The hostname resolves to a non-routable address

Edge servers can't connect to the reserved private ranges, whether you entered one directly as the origin hostname or your hostname resolves to one.

• 10.0.0.0 – 10.255.255.255
• 172.16.0.0 – 172.31.255.255
• 192.168.0.0 – 192.168.255.255

This commonly happens with split-horizon DNS, where the same name resolves to a private address publicly because the public zone was copied from the internal one.

The connection times out

• Firewall. Edge servers connect from a large and changing range of addresses, not from a fixed set you can enumerate once. Confirm your firewall or access control list permits Akamai edge traffic. See access control list solutions.
• Ports. Edge servers connect on port 80 for HTTP and 443 for HTTPS by default. If your origin listens elsewhere, set the connection ports. See Configure origin settings.
• Rate limiting. After cutover, all your traffic arrives from edge servers rather than from many distinct client addresses. Per-source rate limits and connection caps that were never reached before can throttle the entire CDN. Update anything that counts by source address to read True-Client-IP instead.

The origin returns the wrong content or a 404

The host header doesn't match your virtual host

This is the most common cause. Your origin decides which site to serve from the Host header. If Delivery Manager forwards the origin hostname but your virtual host only answers to your public domain, the origin serves its default site or returns a 404.

Either add the origin hostname to your origin's virtual host configuration, or set the forward host header to Incoming host header so edge servers send the hostname the end user requested. See Configure origin settings.

The base path is wrong or doubled

A base path prefixes every request this origin serves.

• 404 on everything. The base path points at a directory that doesn't exist, or it's missing a leading or trailing slash. The value must both start and end with a slash, such as /images/.
• 404 on rewritten paths only. Rules that rewrite the request path append to the base path rather than replacing it. A base path of /images/ plus a rewrite to /gifs/hello.gif requests /images/gifs/hello.gif. Remove the duplicated segment from one or the other.
• 404 on a NetStorage origin. The base path is relative to the CP code directory in your storage group, not to the root of the storage group.

Cache offload dropped after a base path change

Expected, and temporary. The base path forms part of the cache key, so changing it makes all previously cached content unreachable and edge servers refetch it. Offload recovers as the cache repopulates. Make base path changes in a low-traffic window.

TLS and certificate failures

These appear once edge servers connect but can't complete the handshake with your origin.

The certificate isn't valid for the hostname being verified

Edge servers verify the certificate your origin presents against the hostname they're configured to check. A certificate issued only for www.example.com fails against a dedicated origin hostname like 1hkeh1g76-www.example.com.

Either add the origin hostname to the certificate's subject alternative name list, or forward the incoming host header and verify against that name instead.

The certificate chain isn't trusted

Under Use platform settings, edge servers trust certificates signed by any authority in the Akamai Certificate Store. A certificate from a private authority, or one missing its intermediate certificates, fails.

Install the full chain on your origin, or switch to Choose your own certificate and specify what to trust. See Create an origin certificate.

The certificate expired

Under Use platform settings and Choose your own certificate, expiry breaks the connection. A pinned certificate is exempt, because pinning skips the expiration check along with the signature and subject alternative name checks.

A pinned certificate stopped matching

Pinning trusts one exact certificate. Rotating the certificate on your origin without updating Delivery Manager first breaks every request.

Recover by restoring the previous certificate on your origin, then rotate in the supported order: add the new certificate in Delivery Manager alongside the old one, activate, switch your origin, then remove the old one and activate again. See Rotate your origin certificate.

The handshake fails on an origin requiring SNI or TLS 1.3

An origin that hosts several certificates on one address needs Server Name Indication to select the right one. Without it, it returns its default certificate, which then fails verification. TLS 1.3 to the origin also depends on SNI.

Authentication failures

A 403 from the origin usually means the request arrived intact but wasn't authorized.

The access key list is empty

The Access key field shows There are no items to display. Every authentication method except None requires a key, including Akamai Signature Header Authentication, so an empty list blocks the origin from being saved.

• It hasn't finished activating. Activation takes up to 10 minutes.
• It was created for a different authentication method. A key's method must match the method selected on the origin, and a key created for a cloud provider can't be used for Signature Header Authentication.
• It was created for a different contract or group than the one your workspace uses.
• Its deployment network doesn't match your configuration's security level. A PCI-compliant key only works with Enhanced TLS configurations.

Cloud storage returns 403 Forbidden

• Wrong region in the endpoint. For Akamai Object Storage, the region in {bucket-label}.{region}.linodeobjects.com must match where the bucket was created. A mismatch fails signature validation rather than returning a clear not-found error.
• The credentials lost their permissions. The access key identifier and secret stored in Cloud Access Manager must still be valid at the provider, and must still grant read access to the bucket. Rotating or revoking the credentials at the provider without creating a new key version breaks signing.
• The bucket policy blocks the request. Check the provider-side policy independently of Akamai.

Signature Header Authentication requests are rejected

• Secret or key identifier mismatch. The Access key ID and Secret access key stored in the Cloud Access Manager key must be exactly what your origin expects. Because the secret isn't visible after creation, confirm by creating a new key version rather than by trying to read the stored value.
• Algorithm mismatch. Your origin must verify with the algorithm named in the first element of the data header rather than a hard-coded one. Version 5 is SHA256-HMAC, 4 is SHA1-HMAC, 3 is MD5-HMAC.
• Mid-rotation. If you created a new access key version, your origin has to accept both the old and new secret until the new version has propagated. An origin accepting only one rejects whichever requests carry the other.
• Clock skew. If your origin rejects requests outside a timestamp window, an unsynchronized clock rejects valid traffic. Synchronize your origin's clock.
• Enforcement enabled too early. If your origin started rejecting unsigned requests before the Delivery Manager change was activated, it rejects everything. Activate the Delivery Manager change first, confirm signatures validate, then enforce.

See Origin authentication methods.

Caching behaves unexpectedly

Content expires sooner than its TTL

If your origin sits behind another cache or proxy, it may send an Age header. Edge servers subtract that value from the object's freshness lifetime, so objects arrive already partly stale and expire early, lowering offload.

Enable remove the Age header on the origin so edge servers apply the full TTL. See Add an origin.

Two environments share a cache unexpectedly

Objects with the same path and query string served from the same origin hostname share a cache key when the cache key hostname is set to Origin hostname. Set it to Incoming host header to give each service hostname its own cache key. See Configure origin settings.

Changes don't take effect

• The origin isn't referenced. Adding an origin registers it in the workspace. It serves nothing until an environment version selects it.
• The version isn't activated. Origin changes reach the network only through an activation. See Activation workflows.
• You changed a different environment. Origins are workspace-level and shared. Confirm which environment version you activated, and remember that an origin change affects every version referencing that origin.