Start from the server category
Pick the server family first. If the server is labeled Cloudflare, Fastly, CloudFront, Azion, Bunny, CacheFly, Google Cloud, or Direct, that tells you what kind of config is more likely to fit.
CDN type is a route label, not a universal bypass guarantee.
In the app catalog, CDN labels group routes and configs by the edge/network style they were designed for. They help the app match configs to compatible servers and help users understand what kind of host/fronting strategy a route expects. They do not guarantee a provider will always work on every carrier.
What CDN type means inside the app
Server label
A server entry can declare a CDN type so users know whether that route is built around a direct host, a Cloudflare-style edge, a Fastly host, a Google edge, and so on.
Config compatibility
A config can also declare a CDN type. When it does, the app can warn or switch the user to a more compatible server instead of applying a mismatched profile blindly.
Operational grouping
CDN type is mainly a compatibility and routing label. It helps with catalog organization, not only with carrier experiments.
Not an always-on promise
A provider label does not mean the provider will always be reachable or usable in the same way on every ISP, region, carrier, or transport.
CDN families you will see in the app
| CDN type | How it is used in the app | Typical notes |
|---|---|---|
| CacheFly | Specialized edge family used for targeted presets and host-based experiments. | Usually relevant only when a config/server pair was intentionally designed for it. |
| Fastly | Common CDN label for mobile-carrier experiments and edge-hosted routes. | Frequently appears in operator-specific configs where the host/edge matters. |
| Google Cloud | Used when a route is built around Google-hosted edge behavior. | Can appear with WS/XHTTP-style patterns and Google-fronted hosts. |
| Cloudflare | One of the most common catalog families for TLS, WS, XHTTP, and fronted edge routes. | Popular because many routes are provisioned behind Cloudflare-like edges. |
| CloudFront | AWS edge-hosted family used in certain fronted or CDN-routed presets. | Useful when a route specifically targets CloudFront-compatible host patterns. |
| Azion | Edge family used in some catalog routes, especially where Azion-hosted edges matter. | Treat it as its own route family rather than a generic direct host. |
| Bunny | Bunny CDN family, often recognized by b-cdn.net style hosts. | Useful only when the server/config pair was built for Bunny-hosted paths. |
| Direct / custom | Non-CDN or app-defined direct edge family. | May still be internal/proprietary if the route belongs to the official catalog. |
How users should handle CDN-sensitive routes
Apply a matching config
If the config also declares a CDN type, keep it aligned with the selected server whenever possible. The app’s compatibility helpers exist to avoid obvious mismatches.
Treat host and CDN as one package
On CDN-sensitive routes, the host, SNI, path, and transport shape usually matter together. Changing only one piece at random can destroy a working route.
Move to advanced modes only when justified
If a plain TLS/WS route works, keep it. Only move to Socket Custom or V2K if the route fails, is too unstable, or specifically needs a more custom carrier-facing behavior.
What usually breaks CDN-based configs
Mixing a config with the wrong edge family.
Example: selecting a Fastly-tuned config on a Cloudflare-labeled server and expecting the same host/front
behavior.
Changing host, SNI, or path without understanding the route.
CDN-sensitive configs often depend on all of them together, not on a single field.
Assuming a CDN label means infinite reachability.
Even when the provider is correct, the carrier, country, or transport can still reject or reset the route.
Need the sources behind the public catalog?
Open the public servers page to understand which servers are operated by the project and which ones come from external public indexing feeds.