enhanced-FaaS-in-China: a maintained CNAME that re-routes Cloudflare, Vercel and Netlify traffic inside mainland China

The problem: anycast sends mainland users the long way round

Cloudflare, Vercel and Netlify all hand you a CNAME that resolves through anycast. The README's own explanation of why it exists is blunt: from mainland China, the official anycast routes traffic to Southeast Asia with heavy load, while less loaded routes to the United States or Europe exist. The second complaint is stability rather than peak speed. The README states that the official CNAME is sometimes fast on average but inconsistent, with whole provinces unable to reach the site or individual provinces showing very long response times. The third is single-platform risk: if one provider's edge is blocked, a site hosted only there is unreachable everywhere in the country. The intended reader is someone who already deploys static pages or a proxied origin on one of those three platforms and controls the authoritative DNS for the hostname users type. It is not aimed at people who want a Chinese CDN with a contract, and it does not host anything.

How the crawler picks IPs and writes them into A records

The mechanism is a scheduled speed test plus a DNS write. The README describes it as selecting Cloudflare, Vercel and Netlify IPs, testing them periodically, and adding the stable and fast ones as A records for the domain. Mainland traffic is split across the three Chinese carriers; traffic from outside the mainland gets the official A record. The refresh interval stated in the README is roughly every 40 minutes, and the repository ships the results as three JSON files at the top level: Cf.json, Netlify.json and Vercel.json. Those files are the practical interface for anyone who does not want to depend on the hosted CNAME: the README suggests opening them and syncing the IPs into your own A records. IP sources are listed in the README: for Vercel, a public gist plus the A records of cname.vercel-dns.com; for Netlify, the A records behind the official link; for Cloudflare, preferred IPs used by paying Cloudflare customers. The default overseas record is a small JSON map with VERCEL at 76.76.21.21, NETLIFY at 75.2.60.5 and CF pointing at japan.com. The code side is a Python package: crawler.py drives the tests, platforms_to_test holds one module per platform with a run_sub() method, config.py holds settings, and set_DNS_record_to_HWcloud.py is the writer for Huawei Cloud DNS. That last filename is the honest signal about how the hosted service is operated. Route selection relies on the authoritative DNS server's own geo-routing, which the README admits can misjudge location.

Installing it and switching one hostname

For most readers the install step is a DNS edit, not a deployment. The README's worked example is a Vercel blog at blog.domain.com. First point the CNAME at the official Vercel target and wait for the platform to issue the TLS certificate; only then change the record to the project's target, which the README gives as vercel-cname.xingpingcn.top. The same pattern applies to the other two platforms.

# authoritative DNS records for the hostname users visit
# Vercel
vercel-cname.xingpingcn.top
# Netlify
netlify-cname.xingpingcn.top
# Cloudflare
cf-cname.xingpingcn.top

The README marks verlify-cname.xingpingcn.top as deprecated and links issue #35 as the reason, so do not copy that name from older posts. To self-host the crawler instead, the repository includes a Dockerfile and a compose file. The image is built from python:3.11, installs requirements.txt, and the compose service mounts the repository into /bin/enhanced-faas, exposes ports 443 and 80, and runs ./main.py on an external network named faas-proxy.

services:
  enhanced-faas:
    build:
      context: ./
    container_name: enhanced-faas
    volumes:
      - "./:/bin/enhanced-faas"
    expose:
      - 443,80
    command: ./main.py
    networks:
      - faas-proxy

The declared dependencies are only aiohttp and aiosqlite, both pinned to 3.9.3 and 0.20.0 and both conditioned on python_version >= 3.11. Two runtime details are worth flagging before you build. The Dockerfile's own CMD is test.py, a file that does not appear in the top-level listing, so the compose command override to ./main.py is what actually starts the crawler. And the compose file declares the faas-proxy network as external, so it must already exist before the service starts. The README does not document rollback, so plan the reverse edit yourself: point the CNAME back at the official target and let the platform re-issue.

The failure modes the README admits to, and the ones it does not

The most consequential warning is about Cloudflare DNS. If your domain is hosted on Cloudflare and you use cf-cname.xingpingcn.top, the README says you will very likely hit 403, and it recommends hosting the domain elsewhere and deleting the site from the Cloudflare dashboard before using the CNAME. If you need the orange cloud or Workers, the README points to the SaaS-for-CF document instead. The second hard failure is certificate issuance: the deprecated shared CNAME contained IPs from two platforms, so a request could land on either one, and the platform concluded you did not own the hostname. The fix is to point at the official target first, let the certificate generate and cache, then switch. Domain reputation is the third: free subdomains such as eu.org or us.kg, and cheap TLDs such as .xyz or .top, may be blocked by carrier allowlists, and the README's only suggested remedy is changing the domain. Quanzhou is named as the one place that still appears blocked, with the note that the official CNAME has the same problem, so this is not something the project fixes. There is also a misrouting case the README flags itself: its Huawei Cloud DNS has identified mainland users as foreign and returned the default overseas route. Finally, the project's own speed claims are hedged. The comparison images are marked as not updated in time, and the README says the numbers have not changed much. Treat the targets as a stability play, not a bandwidth upgrade: the stated goal is average response under one second, worst case under two, and no more than two provinces returning non-200 codes.

When to skip the hosted CNAME and run the crawler yourself

The hosted CNAME puts someone else's DNS zone between your users and your platform. The alternative the README itself offers is to self-select IPs: open Netlify.json or Vercel.json, add the addresses to your own A records, and keep them in sync. That is more work and it inherits the same 40-minute refresh cadence, but it keeps resolution inside your own zone and removes the third-party dependency. The README also suggests using NS1.COM as the authoritative server with ASN-based routing for more accurate splits than the built-in geo-routing, and links an ASN list for mainland China. If your requirement is a Chinese CDN with a support contract and an SLA, this project is the wrong shape entirely; it is a single operator's DNS zone, and the README gives no availability commitment. If your site is on a platform outside the three supported ones, the Custom section describes the extension path: rewrite crawler.py, add a module under platforms_to_test that implements run_sub(), and adjust config.py. That is a real code change, not a config toggle, and nothing in the repository indicates a plugin API.

Maintenance, licence and what it costs to keep running

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That covers the code and the JSON output, but it says nothing about the availability of the CNAME targets themselves, which are operated under the author's own domain and carry no licence or guarantee. The repository is not archived, so it has not been formally retired, but the repository data gives no last-push date and no releases, so there is no way to judge how frequently it is updated. The upgrade cost is low on the client side, because a CNAME change is a one-line edit, and the reverse edit is equally cheap. The cost sits on the operator side: a crawler that re-tests edge IPs on a roughly 40-minute cycle, a database layer (db.py plus aiosqlite), and a DNS writer bound to Huawei Cloud, which is the component that has already produced a misrouted result. If you fork and self-host, you own that pipeline, including the aiohttp and aiosqlite pins and the Python 3.11 floor. If you use the hosted CNAME, you own none of it and can only observe the outcome. Neither route comes with a documented rollback procedure, so write down the pre-change record before you touch anything.

Editorial conclusion

Adopt it if your site already sits on Cloudflare, Vercel or Netlify, you control the authoritative DNS for the hostname, and you accept that a third party's zone sits in your resolution path. Do not adopt it if your domain must stay on Cloudflare DNS, if you need a contractual uptime commitment, or if you cannot re-point the CNAME back to the official target during certificate issuance. Before switching, confirm which platform you are on, check that your domain is not a free subdomain or a cheap TLD that mainland carriers may block, and read the SaaS-for-CF document if you also need orange-cloud protection.

Frequently asked questions

Official sources

1. Official README
2. Project repository