Cloudflare Workers

Le runtime vanityURLs actuel se deploie comme Worker Cloudflare avec assets statiques. Le Worker est l’origine du domaine court, donc utilisez un Custom Domain Worker plutot que l’ancien modele Pages _redirects ou DNS AAAA 100::.

Carte de navigation Cloudflare

Cloudflare repartit les reglages necessaires a vanityURLs dans trois zones differentes du dashboard. Verifiez le scope du dashboard avant de modifier un reglage; etre dans le bon produit Cloudflare ne suffit pas toujours.

Dans l’interface Cloudflare, la zone de configuration du domaine n’a pas toujours un nom de produit evident. Le meilleur repere est le nom du domaine dans la ligne du haut et un menu lateral avec DNS, SSL/TLS, Security, Rules, Network, et Caching.

Utilisez Zero Trust pour definir qui peut acceder aux chemins prives. Utilisez Workers & Pages pour le Worker lui-meme. Utilisez la configuration du domaine pour trafic, DNS, TLS, et securite de zone.

Forme Worker recommandee

name = "v8s-link"
main = "src/worker.mjs"
compatibility_date = "2026-05-05"
workers_dev = false
preview_urls = false

[build]
command = "npm run build"

[assets]
directory = "./build"
binding = "ASSETS"
not_found_handling = "404-page"
run_worker_first = [
  "/*",
  "!/*.css",
  "!/*.js",
  "!/*.png",
  "!/*.svg",
  "!/*.ico",
  "!/*.webmanifest",
  "!/*.txt",
  "!/*.xml",
  "!/fonts/*",
]

[[routes]]
pattern = "v8s.link"
custom_domain = true

[observability]
[observability.logs]
enabled = true
invocation_logs = true

Les points importants :

• custom_domain = true, car le Worker est l’origine de tout le hostname.
• workers_dev = false et preview_urls = false, car les hostnames publics de preview ne sont pas necessaires en production.
• Binding ASSETS, car le Worker sert les pages statiques depuis build/.
• run_worker_first, car lookup, chemins proteges, blocage de probes et analytics doivent passer avant le fallback asset.
• Workers Logs active, car les metriques Cloudflare sont utiles pour performance et erreurs, mais les evenements applicatifs vont dans les analytics serveur.

DNS et domaines

Pour le domaine court racine, preferez la ligne Worker Custom Domain creee par Cloudflare. Elle doit apparaitre comme record Worker proxifie pour le hostname, par exemple v8s.link -> v8s-link.

Evitez de garder les anciens records synthetiques AAAA 100:: pour le meme hostname une fois le Custom Domain actif. Gardez les records mail, DKIM, DMARC, MTA-STS et verification en DNS-only sauf exigence contraire du service.

Utilisez des records proxifies separes seulement pour de vrais sous-domaines web comme mta-sts, www, ou un site de docs.

Securite de zone

Posture recommandee sur le plan gratuit :

Pour SSL/TLS, partez avec Full (strict), Universal SSL actif, Always Use HTTPS active, TLS 1.3 active, et TLS minimum 1.2. Activez HSTS seulement quand tous les hostnames et sous-domaines de production sont prets pour HTTPS. Un max age d’un mois est un bon premier reglage; incluez les sous-domaines et preload seulement quand toute la zone est volontairement HTTPS-only.

Gardez Automatic HTTPS Rewrites actif. Certificate Transparency Monitoring est optionnel, mais utile si le proprietaire du compte veut recevoir des alertes email pour les certificats inattendus.

Reglages securite

Les reglages de securite du plan gratuit doivent rester simples et explicites. Activez les protections qui reduisent les abus courants, mais evitez les options qui modifient le contenu public ou exposent plus de donnees visiteur sauf besoin clair.

N’activez pas client certificates, regles mTLS, headers de localisation visiteur, ou True-Client-IP pour le shortener public sauf besoin explicite d’un service en aval. Le Worker recoit deja les metadonnees pays et colo Cloudflare pour les analytics agreges.

Reglages Rules et Network

Reglages Rules recommandes :

Reglages Network recommandes :

La normalisation des URLs entrantes est importante parce que WAF, Access et Workers evaluent l’URL normalisee. Gardez la normalisation vers l’origine inactive sauf si une autre origine derriere Cloudflare attend des chemins deja normalises.

WAF et rate limiting

Les regles de securite Cloudflare s’executent avant le Worker. Utilisez-les pour le trafic qui ne devrait jamais consommer de CPU Worker, puis gardez la blocklist Worker comme fallback applicatif.

Jeu de regles recommande :

Exemples d’expressions pour une zone v8s.link :

http.host in {"v8s.link" "www.v8s.link"} and (
  ends_with(lower(http.request.uri.path), ".php") or
  contains(lower(http.request.uri.path), "/wp-") or
  contains(lower(http.request.uri.path), "/.env")
)

http.host eq "v8s.link" and
not http.request.method in {"GET" "HEAD" "OPTIONS"}

http.host eq "v8s.link" and
not cf.client.bot and
not starts_with(http.request.uri.path, "/_stats") and
not starts_with(http.request.uri.path, "/_tests") and
http.request.uri.path ne "/robots.txt"

Le rule builder visuel de Cloudflare peut rendre les expressions imbriquees difficiles a reproduire. Pour ces regles, utilisez l’editeur d’expression pour l’expression finale, collez et validez une expression complete a la fois, sauvegardez les regles desactivees pendant le calibrage, puis activez-les apres verification dans Security Events. C’est plus facile a reproduire que de reconstruire la meme logique avec plusieurs menus deroulants.

Gardez la liste exacte de crawlers IA dans Cloudflare, pas dans la documentation publique, parce que les noms de crawlers et les choix de politique changent. Au minimum, laissez /robots.txt autorise pour que les crawlers lisent la politique publiee.

Politique crawlers IA

Si le depot fournit robots.txt, gardez Cloudflare Managed robots.txt desactive. Le depot reste ainsi la source de verite et Cloudflare ne remplace pas des directives intentionnelles.

Le fichier par defaut defaults/public/robots.txt interdit le crawl par defaut et autorise seulement les fichiers de politique/contexte comme /robots.txt, /llms.txt, et /llms-full.txt. Ces fichiers existent pour decrire le logiciel et la surface deployee, pas pour promouvoir l’inventaire de liens. Une instance vanityURLs est un moteur de redirection, pas un site de contenu public; il n’y a normalement rien d’utile a recolter pour les bots.

Utilisez AI Crawl Control ou une regle WAF sur user-agent si vous voulez que Cloudflare bloque certains crawlers IA avant le Worker. Reproduisez la meme politique dans robots.txt pour la transparence, mais traitez robots.txt comme advisory et la regle WAF comme enforcement.

Defaults utiles :

• Autoriser /robots.txt.
• Autoriser /llms.txt et /llms-full.txt seulement si vous publiez volontairement du contexte lisible par machines.
• Bloquer les crawlers IA et assistants IA non desires dans Cloudflare.
• Garder les crawlers de moteurs de recherche verifies autorises sauf instance volontairement privee.
• Revoir Cloudflare Security Events apres activation, car le trafic bloque n’apparait pas dans les analytics Worker.

Pour un domaine court prive, familial, equipe, ou interne, il est raisonnable de bloquer toutes les familles de crawlers sauf celles que vous voulez explicitement. Ne comptez pas seulement sur robots.txt; utilisez ensemble Cloudflare AI Crawl Control, les regles WAF, et la blocklist runtime.

Operations protegees

Protegez ces chemins avec une application Cloudflare Zero Trust self-hosted :

v8s.link/_stats
v8s.link/_stats/*
v8s.link/_tests
v8s.link/_tests/*

Utilisez une seule application Access self-hosted pour ces operations privees. Configurez les destinations exactement, puis attachez un modele default-deny avec une seule policy allow pour les mainteneurs.

Reglages Access recommandes :

Ne commitez pas les app IDs de fournisseurs d’identite, client secrets, Access audiences, ou service tokens. Gardez-les dans Cloudflare Zero Trust et les secrets Worker. Faites une rotation des secrets fournisseur s’ils apparaissent dans une capture d’ecran, un log, ou un depot.

Definissez le team domain comme variable Worker et l’audience Access comme secret :

[vars]
CF_ACCESS_TEAM_DOMAIN = "<team>.cloudflareaccess.com"

npx wrangler secret put CF_ACCESS_AUD --config wrangler.toml

Le Worker valide l’en-tete Cf-Access-Jwt-Assertion. Si Access n’est pas configure, les chemins proteges restent fermes.

Testez la policy depuis Cloudflare Zero Trust avant release, puis visitez /_stats et /_tests depuis un profil de navigateur deconnecte pour confirmer que les deux chemins sont refuses.

Partage observability

Utilisez les dashboards Cloudflare pour les signaux infrastructure :

• DNS, certificat, et statut TLS
• Worker requests, errors, CPU time, wall time, et request duration
• Evenements WAF, rate limiting, bot, et crawler IA
• Decisions de login Access pour les chemins proteges

Utilisez les analytics serveur vanityURLs pour les evenements applicatifs :

• pageviews
• redirects
• short-link misses
• expand lookups
• evenements bot normalises qui atteignent le Worker

Le trafic bloque par WAF, AI Crawl Control, Access, ou rate limiting n’atteint pas le Worker et doit etre consulte dans Cloudflare Security Events, pas dans Umami ou Fathom.

Build et deploiement

L’integration Git Cloudflare peut executer :

npx wrangler@latest deploy --config wrangler.toml

Le build du depot s’execute avant deploy, copie defaults/, applique custom/, valide v8s.json, et copie le Worker runtime dans src/worker.mjs.

Lancez la meme validation localement avant de pousser :

npm run check

References

• Cloudflare Workers Custom Domains
• Configuration Wrangler
• Workers Logs