If a site is hosted on Vercel, Netlify, or Cloudflare Pages and feels slow from mainland China, the bottleneck is often not the application but the route chosen by the platform's official CNAME. enhanced-FaaS-in-China is an open-source project that targets that layer: it replaces the official CNAME with a screened one, so domestic traffic reaches a faster and more stable edge without changing code or moving servers.
What the project actually does
The tool is built around three moving parts.
-
IP screening and refresh. It periodically collects data from sources such as Vercel and Netlify official A records and Cloudflare paid optimized IP lists. Every 40 minutes it tests response speed and availability, then keeps IPs that meet three conditions: average response time of 1 second or less, maximum response time of 2 seconds or less, and no more than two provinces returning non-200 status codes.
-
Split routing. Traffic from mainland China's three major carriers is resolved to the selected IPs. Traffic from outside China continues to use the platform's official default IPs.
-
CNAME substitution. The project provides ready-made CNAMEs such as
vercel-cname.xingpingcn.top,netlify-cname.xingpingcn.top,verlify-cname.xingpingcn.top, andcf-cname.xingpingcn.top. These are meant to replace the official CNAME and avoid congested routes through Southeast Asia.
It fits static sites, personal blogs, and lightweight apps deployed on Vercel, Netlify, or Cloudflare. It can also be used with Cloudflare CDN when the origin IP needs to stay hidden, including setups that combine Cloudflare with SaaS. Cross-border sites deployed on more than one platform are another good fit because the hybrid CNAMEs reduce the chance that one platform's resolution problem takes the whole site down.
Why official resolution struggles in China
Overseas FaaS platforms usually rely on Anycast. For mainland users, that often means traffic is routed to Southeast Asia, a path that is heavily loaded during normal hours. The official CNAME may look acceptable on average, but stability is another matter: some provinces see timeouts or unusually long responses. Single-platform deployment adds another risk, because if that platform becomes unreachable, every domain pointing to it goes down with it.
A test site at https://blog.hehouhui.cn was deployed to Netlify in a US region, Vercel in a US region, and Zeabur in Indonesia. Before the change, Netlify's response time during the evening peak often exceeded 3 seconds, and some ISPs in Fujian and Henan could not load the site at all.
The optimization path
The core move is not complicated: replace the official CNAME with a screened CNAME from the project, while keeping the rest of the DNS setup intact. For the example site, the Netlify CNAME was the main target.
The reasoning behind it is straightforward. The project refreshes its IP list every 40 minutes, so the selected addresses are more likely to be responsive at that moment. Instead of accepting the platform's default route, the CNAME points domestic users to those screened addresses. When a site runs on both Vercel and Netlify, a hybrid CNAME can be used to lower the risk of one platform's resolution failing.
Configuration details that matter
CNAME changes need to happen at the authoritative DNS provider, for example Huawei Cloud DNS. Using Netlify as the example, the sequence is:
- First point
blog.hehouhui.cnat Netlify's official domain with a CNAME, then wait for the SSL certificate to be issued. This avoids certificate validation failures. - After the certificate is generated, replace the CNAME with
netlify-cname.xingpingcn.top. - If the same site is deployed on both Vercel and Netlify,
verlify-cname.xingpingcn.topcan be used directly to improve fault tolerance.
One special case: if the domain is hosted on Cloudflare, cf-cname.xingpingcn.top may return HTTP 403. In that situation, move the domain to a non-Cloudflare DNS provider such as Huawei Cloud DNS or DNSPod, and remove the corresponding site record from Cloudflare.
There is also an SSL-related trap. If verlify-cname.xingpingcn.top fails after the switch, go back to the official CNAME long enough to generate the certificate, let the certificate cache, and then switch to the optimized CNAME again.
Other practical constraints are worth checking before blaming the CNAME itself:
- Domain type. Free subdomains such as
eu.orgorus.kg, and low-cost suffixes such as.xyzor.top, may be blocked by carrier whitelist rules. A mainstream domain suffix is safer. - DNS provider. Cloudflare DNS resolution is slow in mainland China, and a CNAME adds another recursive lookup. A domestic authoritative DNS provider is usually a better choice.
- SSL certificate. The certificate must be issued before the optimized CNAME is applied, otherwise the site may fail to load.
How to verify the result
After the change, test from more than one platform. zhale.me/http/ shows response time and status codes by province and carrier. ping.chinaz.com/ has broad domestic node coverage and gives a quick view of the three major networks.
Always include the protocol in the test URL, for example https://blog.hehouhui.cn, and cross-check across multiple speed-test sites because the testing services themselves can be inconsistent. Do not hammer the CNAME domains provided by the project. Repeated testing can produce false negatives and may be treated as a DDoS attempt by the platform, even though it does not affect DNS resolution itself.
What changed in practice
The example site improved after the CNAME switch. Average response time settled around 800 ms, with the longest response staying under 2 seconds. Most provinces could access the site normally. Quanzhou remained an exception for some ISPs, but the official CNAME had the same problem there, so it was not introduced by the optimization. Multi-node deployment combined with the preferred CNAME also reduced the impact of a single platform going down.
Extending the setup
Adding another platform, such as Zeabur, requires more work than changing a CNAME. The project's documentation describes the steps: prepare a speed-test tool and an independent domain, rewrite crawler.py, add a test script under the platforms_to_test folder, reimplement the run_sub() method following the existing files, and adjust the filtering configuration in config.py.
For finer-grained routing, there is another option. The IPs listed in the project's Netlify.json or Vercel.json can be added manually as A records in DNSPod. NS1.COM can also be used to configure routing by ASN, the autonomous system number.
For sites deployed on overseas FaaS platforms, enhanced-FaaS-in-China offers a narrow but useful fix: change the CNAME, avoid the worst official routes, and keep the rest of the stack as it is. The example above does not prove that every province and every ISP will be perfect, but it does show that CNAME-level routing can meaningfully improve day-to-day access. The enhanced-FaaS-in-China repository was last updated on Feb 9, 2026.