CDN.com.tr Help

HTTP/3 and IPv6 at the edge

Since September 2026 the CDN.com.tr edge serves every hostname over HTTP/3 (QUIC) and IPv6 in addition to HTTP/2 and IPv4. Browsers switch on their own; there is no per-account setting, and your origin can stay IPv4-only.

Delivery points and DNS

HTTP/3 and IPv6 at the edge

Related edge policies

The protocol and address families are ours; the TLS versions and the DNS records they ride on are described next door.

TLS versions and ciphers

TLS policy at the edge

TLS 1.2 and 1.3 only, server-preferred AEAD ciphers — the policy HTTP/3 is built on.

Your DNS records

DNS records

How the CNAME and apex records that point at the edge inherit the IPv6 side.

Open the topic

Panel path

Not a panel setting
Edge configuration, applied to every account

Prerequisites

A hostname of yours already served by the CDN.
curl 8 with HTTP/3 support, or a browser with DevTools, if you want to reproduce the evidence.

Verification

curl -sI https://www.example.com/ | grep -i alt-svc — the response carries h3=":443".
curl --http3 -sI https://www.example.com/ | head -1 — the status line reads HTTP/3 200.
dig +short AAAA www.example.com — one or more IPv6 addresses are returned; curl -6 -sI https://www.example.com/ reaches the site over IPv6.
In DevTools → Network with the Protocol column enabled, a reload after the first visit shows h3 on the site's own requests.

Use cases

A customer, a tender or your own performance audit asks whether the site supports HTTP/3 or IPv6, or you want to see the switch happen on your own hostname. The answer is the same for every account: both are edge features, on for everyone.

Workflow

Answer from the facts below — they apply to every hostname served by the CDN.
If you need evidence rather than a statement, run the checks in the verification list against your own hostname.
If a visitor reports they never get HTTP/3, look at their network first (UDP 443), not at your account.

Checks

HTTP/3 is announced with Alt-Svc: h3=":443" on every HTTPS response; the browser moves over on its next connection. The first request of a session is HTTP/2 by design.
HTTP/3 needs TLS 1.3, which the edge already requires as its upper protocol; the TLS policy topic describes the full list.
IPv6 is dual-stack: the CDN hostnames have AAAA records next to A records. A CNAME to us inherits both.
Your origin is contacted the way it is today, usually IPv4. Nothing on your server has to change for either feature.
The WAF, rate limits and country rules inspect HTTP/3 requests exactly as HTTP/2 requests; a blocked request gets the same block page and Reference ID.
There is no per-account switch. Both features are edge configuration, applied to every account.

Frequently asked questions

Can we turn HTTP/3 off for one site?

No. It is shared edge configuration. Clients that cannot use it stay on HTTP/2 automatically, so there is nothing to protect by turning it off.

Does IPv6 mean my origin needs an IPv6 address?

No. The edge terminates the visitor's IPv6 connection and fetches from your origin over the address family it has today. Only the edge side became dual-stack.

Our office never sees h3 in DevTools. Is something wrong with the site?

Almost always the office firewall drops outbound UDP 443. Browsers then stay on HTTP/2 silently. Test from a phone on mobile data: if h3 appears there, the site is fine.

Will my IP-based rules still work?

For IPv4 visitors, yes. IPv6 visitors arrive with IPv6 addresses, so a rule that lists only IPv4 addresses does not match them. Add the IPv6 form of the rule where it matters.