Your server has only an IPv6 address, but some website visitors still use IPv4. Can a DDoS-protected CDN bridge the gap?

Yes, if the CDN can accept requests from IPv4 users and connect to your origin over IPv6. 

The user-to-CDN and CDN-to-origin connections are separate and do not have to use the same IP version. Before buying, confirm that the service supports IPv6 origin connectivity and accepts IPv6-only origins. A general claim of “IPv6 support” is not enough.

If the homepage loads after integration but login fails, there is no need to replace the server immediately. Caching, the network path to the origin, and HTTPS settings can all produce that combination of symptoms.

How can IPv4 users reach an IPv6-only origin?

The origin server hosts the website, handles API requests, and runs the application. With a reverse-proxy CDN, visitors typically connect to an edge location rather than directly to the origin. When the CDN needs content from the origin, it makes a separate origin request.

For example, a visitor connects to the CDN over IPv4, and the CDN retrieves a page from the origin over IPv6. The CDN then returns the page over the existing client connection. The browser does not need to know the origin's IPv6 address, and the visitor does not need to configure protocol translation.

DNS alone does not do this. DNS tells the client where to connect; the proxy handles the two separate connections.

This architecture is supported by specific products. Amazon CloudFront's documentation on IPv6 viewer and origin connectivity treats client access and origin connectivity as separate settings. Eligible custom origins can use IPv4-only, IPv6-only, or dual-stack origin connectivity; the IPv6-only option requires the origin hostname to resolve to an IPv6 address.

That is a product-specific capability, not evidence that every DDoS-protected CDN supports the same configuration. This article covers HTTP/HTTPS websites and APIs. Native TCP and UDP ports used by games require separate confirmation of the appropriate proxy and protection services.

What should you ask when a provider says it “supports IPv6”?

A common misunderstanding starts when a provider confirms “IPv6 support,” so the website operator buys a server with no public IPv4 address. During setup, they discover that the CDN control panel still requires an IPv4 origin.

Distinguish IPv6 client access, IPv6 origin connectivity, and IPv6-only origins

These terms describe different requirements:

• IPv6 client access: Users can connect to the CDN over IPv6.
• IPv6 origin connectivity: The CDN can connect to the origin over IPv6.
• IPv6-only origin: The origin has no IPv4 address available for origin requests, so the CDN must connect entirely over IPv6.

Support for the second does not necessarily include the third. Alibaba Cloud CDN's origin configuration documentation currently says that an IP-based origin configuration can contain IPv4 and IPv6 addresses but must include at least one IPv4 address. IPv6 origin connectivity must also be enabled before an IPv6 origin address can be used. This restriction applies to that product and configuration method; it is not a universal CDN requirement.

Describe the use case directly to the provider: “Our origin has a public IPv6 address but no IPv4 address. We need IPv4 users to access an HTTPS website. Does the proposed plan support this at the relevant edge locations? Should we configure the origin by IPv6 address or by an origin hostname with only an AAAA record?”

That question is more useful than simply asking whether IPv6 is supported. As you compare providers, use the guide to choosing a DDoS-protected CDN by application, network path, and protection needs to assess user locations, the origin's data center, and actual origin connectivity together.

A dual-stack origin may still receive traffic over IPv4

A dual-stack origin supports both IPv4 and IPv6. Even if both addresses are configured, the CDN's origin connection policy determines which one it uses.

For example, Cloudflare's IPv6 compatibility documentation says it prefers IPv4 when a proxied record has both IPv4 and IPv6 origin addresses. An AAAA record alone does not prove that origin traffic has moved to IPv6.  

Before retiring an old IPv4 address, verify IPv6 origin connectivity and then update the live configuration. If the IPv6 path to an IPv6-only origin fails, that server has no IPv4 connection available as a fallback.

How should DNS be configured so both groups of users pass through the CDN?

The public website hostname and the origin address configured in the CDN serve different purposes.

For example, www.example.com is the hostname visitors use and should point to the CDN as the provider instructs. The origin address in the CDN control panel points to the actual server. If you use a separate origin hostname, make sure it resolves to the origin rather than back to the same CDN entry point, which would create a loop.

An A record represents an IPv4 address, an AAAA record an IPv6 address, and a CNAME an alias to another hostname. With CNAME-based integration, the IPv4 address needed by users may come from the CDN hostname at the end of the alias chain. You do not necessarily have to create an A record yourself.

Do not point the A record to the CDN but the AAAA record directly to the origin in ordinary DNS settings just to “add IPv6.” This could send some IPv6 users around the CDN, over a different network path and without the protection configured at the edge.

Likewise, hosting DNS with a provider does not automatically enable its proxy. Cloudflare's proxy status documentation distinguishes proxied records from DNS-only records. A DNS-only record does not automatically route website requests through its HTTP proxy protection.

After setup, verify where users actually connect instead of relying solely on a green status indicator in the control panel.

How do you verify IPv4 access and IPv6 origin connectivity?

Test three layers: the public entry point, the origin, and a real application request. The following commands run in a Linux or macOS terminal with dig and curl installed. Replace the example domain with your own.

First, check public DNS and the IPv4 entry point

Query the records for the public website hostname:

dig +short A www.example.com
dig +short AAAA www.example.com

With a CNAME-based setup, the output may show both the alias and its final address. Check whether the A lookup ultimately returns a usable IPv4 address, then compare it with the CDN control panel to confirm that it is the intended entry point.

An empty AAAA result does not necessarily affect IPv4 access or tell you whether the CDN supports IPv6 origin connectivity. It only means this lookup did not return an IPv6 entry point for the public hostname.

Next, send an IPv4 request from a test environment that permits direct internet access:

curl --noproxy '*' -4 -sS \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\ntotal=%{time_total}s\n' \
  https://www.example.com/

remote_ip shows the remote address for this connection, http_code is the HTTP status code, total is the total request time. --noproxy '*' prevents this test from using a proxy configured in the environment, so you do not mistake a connection to that proxy for a direct connection to the website.

An expected response confirms that this particular IPv4 request reached the entry point. Even with a 200 status, check the page content so an error page is not mistaken for a working application. For a 301 or 302 response, inspect the destination hostname as well; a redirect could send users to an address outside the CDN.

If the site also serves IPv6 users, repeat the test from an environment with working IPv6 connectivity, replacing -4 with -6 and running it again. If the test machine has no IPv6 route, a failure cannot automatically be attributed to the CDN.

See the official curl manual for the address-family flags and the address override used below. Here, -4 controls only the client-side connection; it does not show whether the CDN connects to the origin over IPv4 or IPv6.  

Next, confirm the origin actually serves the website over IPv6

Having an IPv6 address assigned to the server does not mean the website is available over IPv6. Check that the web service listens on IPv6 at the right port and that cloud security groups, the host firewall, and public routing permit the connection.

From an authorized IPv6 test environment allowed by the origin's access rules, run:

curl --noproxy '*' -6 -sS \
  --connect-timeout 10 --max-time 30 \
  --resolve 'www.example.com:443:[2001:db8::10]' \
  -D - -o /dev/null \
  https://www.example.com/

2001:db8::10 is a documentation example address. Replace it with your origin's IPv6 address for a real test.

This command connects to the specified IPv6 address while retaining the URL hostname for HTTPS certificate validation, Server Name Indication (SNI) in the TLS handshake, and the HTTP Host header. The example assumes all three use www.example.com; if your origin connection uses a different name, test the corresponding configuration.

For a certificate error, check the trust chain, expiration, and hostname match. For a default site or a 404 response, check the Host header, virtual host, and request path. Do not disable certificate verification to hide a configuration problem or open the origin to the entire internet just for this test.

A successful direct request proves only that this test machine can reach the origin. CDN origin-facing locations use a different network path, which you still need to verify.

Complete the check with a request that actually reaches the origin

A working homepage alongside a failing login API can be more misleading than a site-wide outage.

The explanation may be simple: the CDN serves the homepage from cache without contacting the origin, while login, search, or form submissions require a live origin request.

Create a test path with no sensitive data, such as /origin-check.txt, and have the origin return recognizable content. Explicitly configure the CDN to bypass cache for that path. Request it through the public hostname, then check the corresponding CDN origin logs and origin access logs.

Adding a random query parameter or sending Cache-Control: no-cache in the request does not, by itself, prove that the CDN cache was bypassed. The cache key and provider rules determine the actual behavior.

You should be able to answer three questions: Did the content come from the current origin? Did the origin receive the request? Did the actual origin connection use IPv6? If a real-IP module rewrites the client address in logs, inspect a field that reflects the underlying connection peer rather than relying only on a forwarded visitor IP.

Then use test accounts to check login, APIs, uploads, downloads, and any WebSocket connections the application uses. Do not purge the entire site's cache to investigate one path; that would create unnecessary origin traffic.

Already connected but still seeing failures? Narrow down the cause

Change one variable at a time during troubleshooting. For example, keep the path and protocol constant while changing the test network, or keep the client fixed while comparing a cached path with one that reaches the origin. If you change DNS, certificates, and the origin address together, you may restore access without knowing which change solved the problem.

If the site loads but is slow, use the DNS, TTFB, and resource-loading troubleshooting guide to examine each stage. IPv6 does not guarantee speed. Assess the path from users to edge locations, the path from the edge to the origin, and application processing time separately.

Does an IPv6 origin still need protection after CDN integration?

Yes. The CDN can handle requests that pass through it, but traffic sent directly to the origin's IPv6 address does not automatically pass through the CDN for scrubbing.

The length of an IPv6 address does not make it secret. Public AAAA records, overlooked application subdomains, and content returned by the application can expose the origin address. If you have encountered this issue, use the guide to origin IP exposure and access restrictions to check for paths around the CDN.

After integration, restrict the origin's application ports to expected CDN origin traffic. Configure rules using the provider's actual origin-facing address ranges, and add origin authentication if available. Review IPv4 and IPv6 rules separately; restricting IPv4 does not automatically restrict IPv6.

Preserve the necessary administrative access and establish how to update the rules when origin-facing address ranges change. With a shared CDN egress, allowing a set of source IPs may not be sufficient to identify requests meant for your site; use an authentication method supported by the specific product where appropriate.

Also distinguish application access controls from bandwidth protection. Rejecting requests at the server firewall does not prevent a large attack from saturating the upstream connection. If a publicly reachable IPv6 origin faces direct-attack risk, consider network-level DDoS protection for the origin as well.

When considering CDN07's DDoS-protected CDN for website performance and protection, discuss user locations, the origin data center, and origin connection restrictions before choosing edge locations, bandwidth, and security policies. For an IPv6-only origin, confirm the specific plan's integration requirements before purchase; standard website setup instructions may not apply.  

Frequently asked questions

Can I run a website on an IPv6-only server without buying an IPv4 address?

Yes, if a front-end service provides an IPv4 entry point and can connect independently to the origin over IPv6. Consider email, management panels, and any other services that do not pass through that proxy. A working website does not mean every service on the server is accessible to IPv4 users.

Can IPv4 users reach a domain that has only an AAAA record?

Generally not directly from an IPv4-only network without a separate translation service. To use a CDN for this purpose, the public website hostname needs a working IPv4 CDN entry point. IPv4 users should not be expected to connect directly to the IPv6 origin.

Do I need a new HTTPS certificate after enabling IPv6 on the CDN?

Not solely because the IP version changed. For hostname-based access, the certificates, trust relationships, and name matching must be correct on both the client-to-CDN and CDN-to-origin connections. A valid edge certificate does not establish that the origin certificate meets the CDN's requirements.

Does successful IPv4 access prove that IPv6 origin connectivity works?

No. The response might come from cache, and a dual-stack origin may still be reached over IPv4. Verify with a request explicitly configured to bypass cache and inspect the actual origin connection details.

The origin connection uses IPv6, but the logged visitor IP is IPv4. Is that normal?

It can be. The connection peer is the CDN's origin-facing location, while a forwarding header may contain the original IPv4 visitor address. If the application uses the visitor's real IP, trust forwarding headers only from verified proxies, not from arbitrary clients.

If my DDoS-protected CDN cannot use an IPv6-only origin, must I replace the server?

Not necessarily. Compare a CDN that supports that origin configuration, adding IPv4 to the origin, or deploying a controlled dual-stack reverse proxy. An additional proxy introduces network path, bandwidth, protection, and operational costs, so the server's monthly price is not the only consideration.

Test both connections before going live

• To serve IPv4 users, first confirm that the CDN has a working IPv4 entry point.
• For an IPv6-only origin, confirm that the selected plan supports origin connections using only IPv6.
• A working homepage does not prove origin connectivity. Test a dynamic request or a path explicitly configured to bypass cache.
• Keep IPv6 origin access controls and upstream protection in place after connecting the CDN.

Before integration, gather the website hostnames, origin IPv6 address, data center region, origin port, and HTTPS hostname settings. You can contact CDN07 about integration to confirm which plan fits. Test IPv4 access, IPv6 origin connectivity, and real application requests separately before moving production traffic, so you do not discover after launch that users can load the homepage but cannot complete a task.