TLS Certificates and CDN Architecture: Understanding Every Link in the Encryption Chain
Chapters
In the previous chapter, we covered the VLESS + Reality approach — a powerful option that requires no domain or certificate. But when you need to hide your VPS's real IP address, you'll route traffic through a CDN like Cloudflare. That means understanding TLS certificates and how CDN encryption actually works. Without this knowledge, you'll inevitably misconfigure something during deployment.
This chapter breaks down the full lifecycle of TLS certificates, Cloudflare's two-segment encryption model, and exactly what the GFW can extract from a TLS connection. This is the theoretical foundation you'll need before the hands-on deployment in Chapter 3.
The Role of Certificate Authorities
A Certificate Authority (CA) is the cornerstone of TLS trust. Its job is simple but critical: issue digital certificates that prove a given public key genuinely belongs to a given domain.
Browsers and operating systems ship with a pre-installed list of trusted CAs. Only certificates signed by these CAs are automatically trusted — everything else triggers security warnings.
Common CAs
| CA | Characteristics | Best For |
|---|---|---|
| Let's Encrypt | Free, automated, 90-day validity | Personal sites, small projects |
| Cloudflare | Free, auto-managed, 15-year validity | Cloudflare users |
| DigiCert | Commercial, high assurance | Enterprise |
| ZeroSSL | Free, Let's Encrypt alternative | When LE rate limits hit |
The TLS Handshake: What the GFW Can See
When a TLS connection is established, certain information travels in plaintext before encryption kicks in:
Here's what the GFW can and cannot observe:
| Visible to GFW | Encrypted / Invisible |
|---|---|
| Destination IP address | URL path (/path/to/page) |
| SNI domain name | Request body |
| Certificate issuer | Cookies / Tokens |
| TLS version | Response content |
| Connection timing and data volume | — |
This is why HTTPS alone does not equal privacy from the GFW. It knows which domain you connected to (via SNI), just not what content you accessed on that domain.
Cloudflare's Two-Segment TLS Architecture
When you enable Cloudflare proxying (the orange cloud icon), every HTTPS request passes through two independent TLS connections:
Segment 1: User to Cloudflare
- Certificate issuer: Cloudflare Inc. (not Let's Encrypt, not your CA)
- The browser always sees Cloudflare's certificate
- The IP address resolves to a Cloudflare CDN node shared by millions of websites
Segment 2: Cloudflare to Your VPS
- Which certificate is used here depends on your SSL/TLS settings in the Cloudflare dashboard
- Could be a Cloudflare Origin Certificate (free, 15-year validity)
- Could be a Let's Encrypt certificate
- Could even be a self-signed certificate (in "Full" mode)
The key insight: visitors see Cloudflare's certificate regardless of what's on your server. Your origin certificate only needs to satisfy Cloudflare — not end users.
Implications for GFW Detection
With the two-segment model understood, let's compare what the GFW observes under different configurations:
| Setup | IP Seen by GFW | Certificate Seen by GFW | Risk Level |
|---|---|---|---|
| Direct to VPS + Let's Encrypt | Your VPS IP | Let's Encrypt | High — IP exposed, easily blocked |
| Direct to VPS + CF Origin Cert | Your VPS IP | Cloudflare-issued | High — same problem |
| Cloudflare proxied (orange cloud) | Cloudflare CDN IP | Cloudflare Inc. | Low — blocking = blocking Cloudflare |
The conclusion is straightforward: behind Cloudflare's proxy, the GFW only sees you connecting to Cloudflare — and millions of legitimate websites share those same IP ranges. Blocking Cloudflare means collateral damage to an enormous portion of the internet.
Subdomain Proxy Architecture
In practice, the standard deployment pattern uses your main domain for a legitimate website and a subdomain for the proxy:
How GFW Active Probing Works
When the GFW detects suspicious traffic originating from proxy.example.com:443, it sends its own probe:
What actually determines the probe outcome is your fallback configuration:
Even if your subdomain is behind Cloudflare's proxy (orange cloud), your VPS should still have proper fallback configured. Your VPS's real IP can leak through other channels — historical DNS records, email headers, certificate transparency logs — and direct probing could still occur.
DNS Only vs Proxied: When to Use Each
Cloudflare DNS records have two modes:
| Mode | Icon | Traffic Path | Use Case |
|---|---|---|---|
| Proxied (orange cloud) | 🟠 | Client → CF CDN → VPS | Normal websites, hiding IP |
| DNS Only (gray cloud) | ⚪ | Client → Direct to VPS | Proxy nodes (needs direct connection) |
Why Use DNS Only for Proxy Nodes
WebSocket proxies need a persistent, full-duplex connection between client and server. While Cloudflare does support WebSocket, there are tradeoffs:
- Free plan limitations: Cloudflare's free tier restricts WebSocket connection count and duration
- Added latency: An extra CDN hop adds 30–100ms of latency
- Traffic analysis risk: Cloudflare may detect unusual WebSocket usage patterns
Recommended strategy: run DNS Only by default (direct connection, lower latency). If your VPS IP gets blocked, switch to Proxied mode (route through CDN as a fallback). Toggling this in the Cloudflare dashboard takes seconds.
Certificate Options for Your Proxy Node
For the proxy node specifically, you have a few certificate choices:
Option 1: Cloudflare Origin Certificate (Recommended)
Advantages:
- Free, extremely long validity (15 years)
- Single wildcard cert covers all subdomains
- No renewal scripts needed
Disadvantages:
- Only trusted by Cloudflare (browsers won't trust it directly)
- In DNS Only mode, proxy clients need
skip-cert-verify: true
Option 2: Let's Encrypt
Advantages:
- Globally trusted (browsers accept it directly)
- Free
Disadvantages:
- Expires every 90 days, requires automated renewal
- Separate certificate per subdomain
- Exposes that you're using Let's Encrypt (GFW may flag this)
Practical Recommendations
| Scenario | Recommended Certificate |
|---|---|
| Proxy node (behind CF proxy or client skips cert verify) | Cloudflare Origin Certificate |
| Needs direct browser trust (e.g., decoy website) | Let's Encrypt |
| No domain, no certificate management | Use Reality instead (Chapter 1) |
WebSocket + TLS Encryption Layers
Let's be precise about the full encryption structure in a WebSocket + TLS proxy setup:
What an external observer (including the GFW) sees in a packet capture:
- ✅ A standard TLS 1.3 connection
- ✅ SNI pointing to your subdomain
- ❌ Cannot see WebSocket frame contents
- ❌ Cannot see proxy protocol data
- ❌ Cannot see the actual destination you're browsing
This is the security guarantee of wss:// (WebSocket Secure) — to any observer, it looks identical to any other HTTPS connection.
Three-Scheme Comparison
| Dimension | VLESS + TCP + TLS | VLESS + WS + TLS (+ CDN) | VLESS + Reality |
|---|---|---|---|
| Requires domain | Yes | Yes | No |
| Requires certificate | Yes | Yes (CDN can manage it) | No |
| CDN compatible | No | Yes | No |
| Active probe resistance | Medium | High (with fallback) | Highest (falls back to major sites) |
| Hides VPS IP | No | Yes | No |
| Performance | Good | Medium (multi-layer overhead) | Best |
| Recovery when IP blocked | Change VPS | Switch to CDN proxy mode | Change VPS |
Decision Tree
Summary
This chapter covered the core knowledge around TLS certificates, CDN architecture, and GFW analysis techniques. The key takeaways:
- Cloudflare's orange-cloud proxy ensures the GFW only sees Cloudflare's IP and certificate — your VPS remains invisible
- Fallback configuration is your primary defense against active probing — invalid requests should receive a normal website response
- Origin Certificates are the lowest-maintenance certificate option for proxy nodes
- DNS Only as default + Proxied as fallback gives you the best balance of performance and resilience
With the theory in place, you're ready for the hands-on work.
Next chapter: we deploy a complete VLESS + WebSocket + TLS + CDN proxy on a VPS that already runs a web application — coexisting with your existing site behind a shared Nginx configuration.