CDN WebSockets
One hostname for static assets and live sockets.
Apps often split static files and WebSocket APIs across hosts because the CDN cannot upgrade. That complicates TLS, cookies and CORS.
Cloud CDN supports WebSockets. Cached GET assets stay at the edge. WebSocket upgrades bypass cache and reach the origin.
Why teams use Aptranet
What CDN WebSockets looks like on this network.
Cloud CDN caches and accelerates eligible content on 210+ points of presence, with Origin Shield when the origin must stay out of the way.
Upgrade on the same hostname
Browsers can load JS from cache and open a WebSocket without a second domain.
Assets still hit cache
WebSocket support does not disable caching for the rest of the distribution.
TLS on the public name
wss:// uses the same certificate map as https://.
How to set it up
A cutover you can validate before DNS moves.
Create the Cloud CDN configuration, prove it on an Aptranet hostname, then point production DNS when the path looks correct.
- 1Front the app origin
Pull the HTTP origin that already speaks WebSockets.
- 2Cache static paths
JS, CSS and images stay cacheable.
- 3Allow the upgrade path
The WebSocket URL bypasses cache and reaches origin.
- 4Test from more than one region
Confirm upgrades, heartbeats and reconnects through the edge.
Outcomes
What changes once the hostname is on Aptranet.
- WebSockets share the site hostname
- Static files remain cached
- TLS is unified
- Origin still owns socket state
Keep reading
Related pages
More CDN use cases on the same Cloud CDN footprint.
Frequently Asked Questions
No. The upgrade and the data plane are dynamic. Only ordinary HTTP GETs are cached.
If Socket.IO falls back to HTTP long-polling, those POSTs/GETs must bypass cache. The WebSocket transport upgrades dynamically.
No. Cloud CDN is the path to your origin. Presence, fan-out and channel logic stay in your app or vendor.
Plan idle timeouts with your origin. Validate long-lived connections before production cutover.