Background
We operate multiple websites hosted across different servers, with some origin servers located in Hong Kong and others within mainland China. When users in mainland China connect directly to the Hong Kong origin servers, the Time To First Byte (TTFB) often exceeds 2–3 seconds, resulting in a poor user experience. Enabling Cloudflare’s “Proxied” mode sometimes improves performance, but may also trigger errors such as HTTP 522 (“Origin Connection Timeout”).
After conducting a systematic optimization effort, we have developed and refined a comprehensive multi-site acceleration solution — shared here for others facing similar challenges.
Core Architecture
Based on the geographic location of the origin server, traffic is routed via two distinct paths:
Path A: Origin server located overseas (e.g., Hong Kong)
Users in mainland China → Cloudflare CDN edge node → Edge reverse proxy server (co-located with origin) → Origin server
Advantage: Latency between edge proxy and origin is <1 ms; Cloudflare-to-proxy origin fetches are highly stable.
Path B: Origin server located within mainland China
Users in mainland China → Cloudflare CDN edge node → Origin server (direct connection)
Advantage: Leverages Cloudflare’s global network for acceleration; SSL termination handled by Cloudflare; origin IP remains hidden.
Key decision: Not all sites should follow the same path. For overseas origins, routing through an edge reverse proxy yields excellent results; for domestic origins, direct Cloudflare-to-origin connections are faster — adding an extra hop (e.g., via a Hong Kong proxy) only increases latency.
Path A: Implementing Edge Reverse Proxy
Why Use an Edge Reverse Proxy?
Directly configuring Cloudflare to fetch from overseas origin servers introduces several issues:
- The origin may only allow access from specific IPs; whitelisting Cloudflare’s entire IP range incurs high maintenance overhead.
- SSL handshakes may fail during Cloudflare’s origin fetch (e.g., due to self-signed certificates or SNI misconfiguration).
- During origin load fluctuations, Cloudflare’s direct connections can become unstable.
An edge reverse proxy deployed in the same network environment as the origin acts as a stable intermediary layer.
Key nginx Reverse Proxy Configuration
server {
listen 80;
server_name example.com;
# Restore real client IP (Cloudflare IP ranges)
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ... include all official Cloudflare IPv4/IPv6 ranges
real_ip_header CF-Connecting-IP;
location / {
proxy_pass https://origin-internal-or-same-rack-IP;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Critical: Enable SNI; otherwise SSL handshake fails for multiple domains sharing one IP
proxy_ssl_server_name on;
proxy_ssl_name $host;
# Disable SSL verification if origin uses self-signed certificate
proxy_ssl_verify off;
}
}
Lessons learned (common pitfalls):
-
proxy_ssl_server_name onis mandatory: If your origin runs OpenResty/nginx hosting multiple domains on a single IP, omitting SNI causes Cloudflare to receive the wrong certificate — leading to 502 errors. -
Use
CF-Connecting-IP, notX-Forwarded-For, forreal_ip_header: Cloudflare places the true client IP in theCF-Connecting-IPheader.X-Forwarded-Formay be polluted by intermediate proxies. -
Reverse proxy listens only on port 80: Cloudflare handles HTTPS termination (SSL mode set to Flexible); the reverse proxy requires no TLS certificate. Cloudflare connects to the proxy over HTTP on port 80.
Cloudflare Configuration (Path A)
- A record: Point to the edge reverse proxy’s public IP, with Proxied (orange cloud) enabled.
- SSL/TLS mode: Flexible (HTTPS between Cloudflare and end-user; HTTP between Cloudflare and reverse proxy).
- If the origin has a valid, publicly trusted certificate, you may use Full mode (HTTPS between Cloudflare and origin).
Path B: Direct Cloudflare-to-Domestic-Origin Connection
Domestic origins do not require an edge reverse proxy — Cloudflare can fetch directly. However, a common pitfall exists:
Troubleshooting HTTP 522 Errors
Two of our sites consistently returned 522 after Cloudflare integration. Investigation revealed:
Root cause: Cloudflare’s default SSL mode is Full, meaning it attempts HTTPS connections to port 443 on the origin. If the origin uses a self-signed certificate or has misconfigured TLS, Cloudflare’s SSL handshake fails → timeout → 522.
Solution: Switch SSL mode from Full to Flexible. Cloudflare then fetches from the origin over HTTP port 80, bypassing certificate validation entirely.
How to diagnose:
- From another machine:
curl -skI https://origin-IP -H 'Host: domain-name'succeeds → origin itself is healthy. - But Cloudflare fails → strongly indicates an SSL mode mismatch.
- Also verify that the origin’s firewall permits inbound traffic from Cloudflare’s IP ranges.
NS Migration Considerations
Some domains still use nameservers from their registrar (e.g., HiChina/Alibaba Cloud). To enable full Cloudflare DNS management, you must migrate nameservers to Cloudflare’s.
- Nameserver propagation typically takes several hours to 24 hours.
- During migration, verify Cloudflare-side readiness using:
dig domain-name @cloudflare-assigned-ns. - Until global propagation completes, some users may still resolve via legacy nameservers.
Real-World Results
| Site | Pre-Optimization TTFB | Post-Optimization TTFB | Strategy |
|---|---|---|---|
| Tech Forum (Discourse) | 3.0s | 0.7s | Path A: Edge reverse proxy |
| WordPress Site A | 0.6s | Pending verification | Path A: Edge reverse proxy |
| WordPress Site B | 1.5s | Pending verification | Path B: Direct Cloudflare-to-origin |
The forum saw the most dramatic improvement — Discourse itself responds in just ~0.06s; the prior 3s TTFB was almost entirely network latency. With Cloudflare + edge reverse proxy, mainland users connect to Cloudflare’s nearest edge node, Cloudflare fetches from the co-located proxy, and the proxy forwards to the origin — drastically reducing end-to-end latency.
Automation: Optimizing Cloudflare IP Selection
Cloudflare’s Anycast IPs perform very differently across ISPs and regions in mainland China. We deployed the CloudflareSpeedTest automated pipeline on a mainland server:
- Automatically measures latency every 6 hours, selecting optimal IPs per ISP (China Telecom, China Unicom, China Mobile).
- Compares results against previous run; automatically updates split-horizon DNS records via Cloudflare API when improvements are found.
- Critical: Speed tests must run from within mainland China — results from overseas locations are irrelevant for mainland users.
This pipeline is currently undergoing refinement to resolve DNS API compatibility issues; once fully operational, it will continuously optimize domestic access speed.
Security Hardening
Edge reverse proxy servers are exposed to the public internet — baseline security is non-negotiable:
- SSH key-based authentication only; password login disabled.
fail2banconfigured (e.g.,sshdjail: 5 failed attempts → 1-hour ban).ufwconfigured with default inbound deny policy; only essential ports open (SSH + HTTP).- Treat as a “disposable” node: no persistent data stored; full re-deployment and service recovery achievable via Ansible in one command.
Summary
- Route by origin location: Use edge reverse proxy for overseas origins; direct Cloudflare-to-origin for domestic origins.
- SSL mode is critical: Most 522 errors stem from incorrect SSL mode choice (Full vs. Flexible).
- Never omit SNI:
proxy_ssl_server_name onis mandatory when multiple domains share one origin IP. - Edge reverse proxy is extremely lightweight: A single 2-CPU / 4-GB RAM entry-level server can comfortably handle reverse proxying for a dozen+ sites.
- Cloudflare IP optimization must be performed domestically: Overseas test results hold zero relevance for mainland users.
We hope this guide proves helpful to others with similar infrastructure needs. Feel free to reach out with questions or suggestions.