enhanced-FaaS-in-China : accélération par CNAME pour Cloudflare, Vercel et Netlify en Chine
Voir cloudflare, vercel et netlify cf. cf优选ip | éruption nuageuse | vercel | netlifier | 加速 | 国内 | 中国 | 境内 | 大陆.
En bref
- De quoi s’agit-il ?
- Un projet Python qui publie des cibles CNAME et des listes d'IP choisies pour améliorer l'accès depuis la Chine aux sites hébergés sur trois plateformes.
- À qui s’adresse-t-il ?
- Le projet est un outil petit et ciblé : il maintient des enregistrements CNAME et des listes d'IP qui contournent les chemins congestionnés, et il documente où ces choix fonctionnent et où ils échouent. L'étendre à une autre plateforme exige de réécrire crawler.py et d'ajouter un module de plateforme, ce que le README ne fait qu'esquisser.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Des enregistrements CNAME qui redirigent le trafic de Chine
Le README présente le projet comme un moyen d'améliorer la vitesse et la stabilité d'accès en Chine pour des pages hébergées sur cloudflare, vercel ou netlify, en changeant uniquement un enregistrement CNAME. Les trois cibles sont vercel-cname.xingpingcn.top, netlify-cname.xingpingcn.top et cf-cname.xingpingcn.top. L'ancien nom verlify-cname.xingpingcn.top est marqué comme abandonné dans le ticket #35. Le changement ne se fait pas côté client : l'utilisateur modifie, sur son serveur DNS faisant autorité, l'enregistrement CNAME du domaine que les visiteurs utilisent, par exemple app.domain.com, pour le remplacer par l'enregistrement choisi de la plateforme correspondante. Le README insiste sur le fait qu'il faut d'abord pointer le CNAME vers le domaine officiel pour que la plateforme émette un certificat SSL, puis seulement basculer vers l'enregistrement choisi.
L'ancien nom d'enregistrement et les domaines hébergés chez Cloudflare
La section d'utilisation contient deux avertissements. Premièrement, verlify-cname.xingpingcn.top est abandonné ; quand un site devient inaccessible après le changement, c'est probablement parce que ce vieux nom a été utilisé, car cet enregistrement contient des IP de deux plateformes et la plateforme reçoit l'une ou l'autre à chaque accès, ce qui l'empêche de reconnaître le domaine comme vous appartenant. La solution est de revenir au lien officiel, d'attendre la génération du certificat SSL, puis de refaire le réglage. Deuxièmement, si le domaine est hébergé chez Cloudflare, l'utilisation de cf-cname.xingpingcn.top risque de provoquer une erreur 403. Le README recommande d'héberger le domaine sur un fournisseur DNS autre que Cloudflare et de supprimer le site de Cloudflare avant d'utiliser l'enregistrement. Pour les services qui doivent rester chez Cloudflare, comme Cloudflare Workers ou des IP de VPS protégées par le nuage orange, le README renvoie à un document séparé expliquant comment utiliser la fonction SaaS de CF.
Comment sont construits les enregistrements maintenus
Le projet sélectionne des IP de cf, vercel et netlify, teste leur vitesse régulièrement et ajoute les IP stables et rapides aux enregistrements A du domaine. Pour la Chine continentale, les réponses DNS sont optimisées par réseau ; hors de Chine, les enregistrements A officiels sont utilisés. Le README indique une mise à jour environ toutes les 40 minutes. Les sources d'IP comprennent un gist pour Vercel, les enregistrements A du cname.vercel-dns.com officiel, les enregistrements A des liens officiels pour Netlify, et des IP choisies par divers utilisateurs payants de Cloudflare. Les IP par défaut hors de Chine sont données en JSON dans le README : VERCEL vaut 76.76.21.21, NETLIFY vaut 75.2.60.5, CF vaut japan.com.
Les comparaisons de vitesse sont des captures, pas un benchmark publié
La section de comparaison du README contient des captures datées, par exemple l'heure de pointe du soir à 23 h UTC+8, présentées comme la vitesse optimisée. La même section montre des images comparatives avec les CNAME officiels. Ces images sont des fichiers du dépôt ; le README ne publie pas les chiffres bruts, l'outil de test utilisé, ni une méthodologie au-delà des horodatages. La section précise que les résultats peuvent ne pas être à jour et que Quanzhou semble bloquée lors des tests récents. La section sur les tests avertit de ne pas tester directement les domaines du projet, car trop de tests peuvent être considérés comme un DDoS par les plateformes et produire des faux négatifs. Les résultats d'itdog.cn peuvent montrer de grandes zones rouges pour une raison inconnue ; boce.com, cesu.net et le test de dial d'Alibaba Cloud sont suggérés comme alternatives.
Ce que la section FAQ dit réellement
La FAQ explique pourquoi un utilisateur ne voit pas la même vitesse que les images de comparaison après le changement. Les raisons listées sont : la plateforme de test elle-même ; le domaine (les domaines de second niveau gratuits comme eu.org ou us.kg, et les domaines bon marché comme .xyz ou .top, peuvent être bloqués par des mécanismes de liste blanche des opérateurs) ; le problème d'origine, car les comparaisons ont été faites avec des pages statiques déployées sur Cloudflare Pages, Vercel et Netlify ; et les problèmes de résolution DNS. Sur ce dernier point, le README dit que le DNS de Cloudflare est lent en Chine continentale et qu'un CNAME ajoute une résolution récursive supplémentaire ; il recommande de confier le domaine à un DNS faisant autorité situé en Chine. Il mentionne aussi les trois fichiers JSON à la racine du dépôt, qui contiennent des IP mises à jour en continu et peuvent être copiées dans vos propres enregistrements A. Un incident concret est décrit : le DNS de Huawei Cloud a identifié des utilisateurs chinois comme étrangers et résolu vers la route par défaut, par exemple japan.com.
La personnalisation exige d'écrire du Python, pas de modifier un fichier de configuration
Pour ajouter une troisième plateforme comme render ou railway, le README indique qu'il faut préparer un outil de mesure de vitesse et un domaine, réécrire crawler.py, créer un nouveau fichier .py dans platforms_to_test en imitant les autres fichiers du dossier et en réécrivant la méthode run_sub(), puis modifier config.py. Le README ne donne pas le détail de l'interface de run_sub(), le format de config.py, ni la procédure de test. Le langage du dépôt est Python ; en dehors du lien vers le document sur l'usage SaaS pour CF, les métadonnées ne listent aucun autre répertoire de documentation.
La licence MIT et ce qu'elle ne promet pas
Le dépôt est publié sous licence MIT, copyright 2024 xingpingcn. La licence autorise à utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre des copies du logiciel, à condition que l'avis de droit d'auteur et l'avis de permission ci-dessus soient inclus dans toutes les copies ou parties substantielles. Le logiciel est fourni tel quel, sans garantie d'aucune sorte, y compris les garanties de qualité marchande, d'adéquation à un usage particulier et d'absence de contrefaçon. Le texte de la licence ne dit rien sur la fiabilité opérationnelle des enregistrements CNAME, l'exactitude des listes d'IP, ni sur un engagement de support. Si quelqu'un affirme que le projet garantit un accès plus rapide depuis la Chine, cette affirmation devrait venir d'un autre matériau que cette licence ; le README lui-même décrit seulement le mécanisme et montre des captures, sans promettre une vitesse précise. Pour enhanced-FaaS-in-China, la séquence documentée est précise : laissez d'abord le CNAME officiel de Vercel, Netlify ou Cloudflare produire le certificat SSL, puis remplacez-le par `vercel-cname.xingpingcn.top`, `netlify-cname.xingpingcn.top` ou `cf-cname.xingpingcn.top`. Le nom `verlify-cname.xingpingcn.top` est abandonné. Mesurez avec le protocole explicite et plusieurs services, en écartant les domaines du projet pour éviter les faux négatifs liés aux sondes répétées. Le README signale un risque de 403 lorsque la zone reste chez Cloudflare et propose le mode SaaS pour certains cas. Les différences entre provinces, opérateurs et heures de pointe rendent les captures historiques insuffisantes pour conclure sur votre domaine.
Conclusion éditoriale
Le projet est un outil petit et ciblé : il maintient des enregistrements CNAME et des listes d'IP qui contournent les chemins congestionnés, et il documente où ces choix fonctionnent et où ils échouent. L'étendre à une autre plateforme exige de réécrire crawler.py et d'ajouter un module de plateforme, ce que le README ne fait qu'esquisser. Pour enhanced-FaaS-in-China, la séquence documentée est précise : laissez d'abord le CNAME officiel de Vercel, Netlify ou Cloudflare produire le certificat SSL, puis remplacez-le par `vercel-cname.xingpingcn.top`, `netlify-cname.xingpingcn.top` ou `cf-cname.xingpingcn.top`. Le nom `verlify-cname.xingpingcn.top` est abandonné. Mesurez avec le protocole explicite et plusieurs services, en écartant les domaines du projet pour éviter les faux négatifs liés aux sondes répétées. Le README signale un risque de 403 lorsque la zone reste chez Cloudflare et propose le mode SaaS pour certains cas. Les différences entre provinces, opérateurs et heures de pointe rendent les captures historiques insuffisantes pour conclure sur votre domaine.
Notes de la communauté