enhanced-FaaS-in-China: A CNAME-Based Shortcut for Faster Cloudflare, Vercel, and Netlify Sites in Mainland China

What It Fixes and Who It Serves

The problem is familiar to anyone who hosts a site on Cloudflare, Vercel, or Netlify and has users in mainland China. Official anycast routes often send traffic to Southeast Asia, which is congested, while less loaded routes through the US or Europe exist but are not chosen. The official CNAME can be fast on average but unstable, with several provinces failing or responding very slowly. This project addresses that by providing alternative CNAME records that point to a curated set of IPs. The target user is a developer who has already deployed on one of the three platforms and wants a quick fix: change one DNS record and nothing else. The README is explicit that the solution is for static or edge-served content, not for origin servers behind a CDN unless you also use Cloudflare's SaaS feature. It is a pragmatic stopgap for speed and stability, not a full CDN replacement.

The Mechanism: A Scheduled IP Picker Behind a CNAME

The core idea is simple. The project picks IPs from Cloudflare, Vercel, and Netlify, tests them periodically for speed and stability, and adds the best ones as A records on a domain the author controls. The public CNAME records, such as vercel-cname.xingpingcn.top, resolve to those A records. The selection runs roughly every 40 minutes, according to the README. For mainland China, the DNS server returns different IPs based on the requesting network, using the authoritative DNS server's built-in route resolution. For users outside China, it falls back to the official default IPs, which are listed in a JSON snippet: VERCEL 76.76.21.21, NETLIFY 75.2.60.5, and CF japan.com. This split approach means international visitors get normal routing, while domestic visitors get the optimized set. The project also publishes three JSON files (Vercel.json, Netlify.json, and presumably a CF equivalent) that contain the current IP lists, so you can manually sync them to your own A records if you prefer not to use the CNAME.

Getting It Running: The CNAME Swap and Its Prerequisites

The usage is a DNS change. For a Vercel deployment, set your domain's CNAME to vercel-cname.xingpingcn.top. For Netlify, use netlify-cname.xingpingcn.top. For Cloudflare, use cf-cname.xingpingcn.top. The README warns that an older name, verlify-cname.xingpingcn.top, is deprecated and should not be used. The recommended order is to first point your CNAME to the official platform domain, wait for the SSL certificate to generate in the platform's console, and then switch to the optimized CNAME. If you switch too early, the platform may not recognize the domain as yours because the CNAME resolves to IPs from multiple platforms, causing certificate issues. For Netlify, you can upload your own certificate if needed. A critical prerequisite is that your domain should not be hosted on Cloudflare DNS. The README states that using this CNAME with Cloudflare DNS often results in a 403 error. The suggested workaround is to move your domain to a non-Cloudflare DNS provider, such as Huawei Cloud, and then delete your site from Cloudflare. If you must keep the domain on Cloudflare for Workers or orange-cloud protection, the README points to a separate guide for using Cloudflare's SaaS feature.

Speed Testing and the Pitfalls of Measurement

The README includes a section on how to test speed, and it is unusually honest about measurement problems. It warns that you must include the protocol in the test URL and use multiple speed test websites because the test sites themselves can be unreliable. It specifically says not to test the project's own CNAME domains because too many test requests can be mistaken for DDoS by the platforms, which would produce false negatives. The README also notes that itdog.cn gives strange results with large red areas for unknown reasons, and suggests boce.com, cesu.net, or Alibaba Cloud's synthetic monitoring instead. The project provides comparison screenshots in a collapsible section, showing peak-hour tests for CF, Vercel, and Netlify against official CNAMEs. However, the images are not visible in the material, so you cannot verify the actual numbers. The author's stated goal is to keep average response time under one second, maximum response time under two seconds, and no more than two provinces returning non-200 status codes. That is a concrete target, but you should treat the screenshots as anecdotal evidence, not a benchmark you can reproduce.

Known Failures and Wrong-Tool Cases

The project has documented limitations. The README mentions that some ISPs in Zhejiang, Fujian, and Henan had access failures, though it says only Quanzhou is currently blocked, and the official CNAME has the same issue, possibly due to ISP restrictions. It also warns that cheap or free domains, like eu.org, us.kg, .xyz, or .top, may be blocked by operator whitelist mechanisms, and the only fix is to change the domain. The biggest failure mode is the 403 error when your domain is on Cloudflare DNS. The README is clear that this happens and that you must move your domain off Cloudflare and delete your site there. Another failure is route misjudgment by the authoritative DNS server. The author uses Huawei Cloud DNS, and the README notes a case where domestic users were identified as foreign, causing them to get the default route like japan.com. That means the optimization silently fails for those users. Also, if a specific route's IPs are all poor quality, the project stops resolving that route and falls back to the official default IP, which is not an error but a degradation. If you need precise route control, this CNAME is the wrong tool; the README itself suggests DNSPod or NS1.com with ASN-based routing for that.

Alternatives: DIY A Records or Cloudflare SaaS

The README offers two concrete alternatives. First, you can skip the CNAME entirely and manually add the IPs from the repository's JSON files to your own A records. The README points to Vercel.json and Netlify.json as live-updated lists. This gives you control over which IPs you use and lets you choose a DNS provider with better route resolution, such as DNSPod. The trade-off is that you must update the records yourself, or write a script to do it, because the IPs change roughly every 40 minutes. Second, if you must keep your domain on Cloudflare DNS, the README recommends using Cloudflare's SaaS feature, which allows you to use a custom hostname on your own domain while keeping the domain on Cloudflare. That approach avoids the 403 issue but requires more setup, as described in the linked document. The difference is that the CNAME is a zero-maintenance shortcut for most users, while the alternatives require either manual DNS management or a more complex Cloudflare configuration.

Maintenance, Licensing, and Upgrade Cost

The project is written in Python and licensed under MIT, so you can reuse the code freely, but the README does not detail installation or deployment steps for the crawler itself. The maintenance cost is on the author's side: they run the speed tests and update the DNS records. For users, the cost is minimal: you change a CNAME record once and occasionally check if the speed is still good. However, there is an upgrade cost if you want to customize the project. The README describes how to add a third platform, like Render or Railway, but it requires rewriting crawler.py, creating a new .py file in platforms_to_test that implements the run_sub() method, and modifying config.py. That is a significant development effort, and the README does not provide examples or API details, so you would need to read the source code. The project has no releases or versioning mentioned, and the last push date is unknown, so you cannot assess how actively it is maintained. The JSON files are updated every 40 minutes, which suggests the infrastructure is running, but you should check the repository's recent commit history before relying on it long-term. The license is permissive, but the real cost is the dependency on a third-party domain (xingpingcn.top) that could be taken down or rate-limited, so you should have a fallback plan if you adopt this.

Editorial conclusion

Adopt this project if you deploy static or serverless sites on Cloudflare, Vercel, or Netlify, want better China mainland access without changing your platform, and can move your domain away from Cloudflare DNS. Do not use it if your domain must stay on Cloudflare for Workers or orange-cloud protection, or if you cannot tolerate occasional route misjudgments from Huawei Cloud DNS. Before adopting, verify that your domain is not on an ISP blocklist (the README notes Quanzhou is currently blocked), test with multiple speed tools like boce.com or cesu.net rather than itdog.cn, and check that your SSL certificate is generated before switching the CNAME. Also review the three JSON files in the repository to see the current IP lists; if you need precise routing, consider hosting your own A records with a DNS provider like DNSPod instead of relying on this CNAME.

Official sources

1. Official README
2. Project repository