Une erreur s’est produite lors de ma mise à jour
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
Merci de m’aider à la corriger.
Je n’étant pas un développeur expérimenté (je dirais que je suis plutôt au niveau basique), essayer la solution nginx pour afficher une page de maintenance a été un peu un cauchemar. Aujourd’hui, cette idée m’est venue et j’ai décidé de demander à Claude si cela était possible, maintenant que j’utilise Railway pour d’autres sites web et applications :
« Puisque Discourse utilise Docker, il semble très compliqué d’afficher un message de maintenance, car cela nécessite nginx, ce qui est un processus compliqué pour moi.
Puis-je, via Railway ou tout autre service, créer un “commutateur” qui redirige rapidement le trafic d’un serveur vers un autre ?
Par exemple, en ce moment, Cloudflare redirige example.com vers mon serveur Hetzner où Discourse est installé.
Pourrais-je envoyer Cloudflare vers un projet/environnement/service Railway où ce “commutateur” serait implémenté et où changer la valeur d’une variable de “maintenance” à “live” (en ligne) redirigerait le trafic soit vers un autre service Railway pour la page de maintenance, soit vers Hetzner ?"
Et la réponse de Claude :
Oui, techniquement cela fonctionne, mais faire passer le commutateur par Railway est la mauvaise couche pour cela. Vous ajouteriez un deuxième saut réseau (Cloudflare → Railway → Hetzner) pour chaque requête lorsque Discourse est en ligne, ce qui signifie :
- Une latence supplémentaire sur chaque requête, de manière permanente, et pas seulement pendant la maintenance
- Un nouveau point de défaillance unique (si le service Railway tombe, Discourse tombe même s’il est sain)
- Des coûts de sortie (egress) sur Railway pour tout votre trafic normal, et pas seulement pendant les fenêtres de maintenance
Meilleure approche : effectuer le commutateur dans un Cloudflare Worker. Les Workers s’exécutent au niveau du périmètre (edge, plus de 300 PoPs), donc il n’y a pas de temps de trajet supplémentaire lorsque vous êtes en mode “live”, et le basculement est instantané.
Architecture :
Cloudflare Worker (lié à example.com)
→ vérifie la valeur KV "maintenance_mode"
→ si "off" (désactivé) : fetch(requête d'origine vers l'IP/nom d'hôte Hetzner) et la renvoie
→ si "on" (activé) : renvoie le HTML de maintenance statique directement depuis le Worker
Le basculement se fait via une écriture KV (via un appel API ou le tableau de bord), et non via un redéploiement. La propagation se fait en quelques secondes, aucun push de code n’est nécessaire.
Worker minimal :
export default {
async fetch(request, env) {
const mode = await env.MAINTENANCE_KV.get("mode"); // "on" ou "off"
if (mode === "on") {
return new Response(MAINTENANCE_HTML, {
status: 503,
headers: { "Content-Type": "text/html", "Retry-After": "3600" },
});
}
// transmet vers Hetzner sans modification
return fetch(request);
},
};
const MAINTENANCE_HTML = `<!DOCTYPE html><html><body><h1>De retour très bientôt</h1></body></html>`;
Configuration :
1. Créez un espace de noms KV, liez-le en tant que MAINTENANCE_KV.
2. Définissez la route du Worker sur example.com/*.
3. Basculez avec wrangler kv:key put --binding=MAINTENANCE_KV mode "on" ou via l’API Cloudflare depuis un script shell.
Cela vous donne exactement le comportement “changer une variable, le trafic est redirigé” que vous avez décrit, sans toucher à la configuration nginx/docker de Discourse, et sans ajouter de saut réseau supplémentaire permanent pour votre trafic en ligne.
Un point à vérifier avant de construire cela : votre proxy Cloudflare effectue-t-il actuellement un simple passage DNS ou est-il déjà proxifié (cloud orange) ? Si c’est un simple passage DNS pour le moment, les Workers n’intercepteront rien, vous devrez d’abord passer cet enregistrement en mode proxifié.
Je serais donc intéressé de savoir si la réponse de Claude est valide et peut effectivement être mise en œuvre ? S’agirait-il d’un basculement instantané et tous les utilisateurs seraient-ils présentés avec la page de maintenance ? Ou cela redirigerait-il certains utilisateurs vers l’installation Hetzner, leur montrant la page cassée, en raison d’un cache impliqué ?
Et en répondant à Claude : Oui, mon example.com est proxifié chez Cloudflare.
J’ai ensuite décidé d’ouvrir une nouvelle fenêtre Claude et de poser des questions sur cette interaction, et j’ai obtenu ceci (il semble donc qu’un peu plus de travail soit nécessaire :
L’architecture est solide. Les Cloudflare Workers sur une zone proxifiée (cloud orange) interceptent les requêtes au niveau du périmètre avant qu’elles n’atteignent Hetzner, donc la conception fonctionne. Mais l’affirmation “instantané, tous les utilisateurs le voient” doit être nuancée :
Ce qui est réellement vrai :
La correspondance des routes du Worker est rapide, effectivement immédiate une fois déployée
Les écritures KV se propagent globalement, mais pas instantanément — la documentation de Cloudflare indique jusqu’à 60 secondes pour que le KV se réplique sur tous les emplacements edge. Certains utilisateurs pourraient rencontrer l’état “off” obsolète pendant jusqu’à une minute après le basculement.
Puisque Discourse est déjà proxifié via Cloudflare, le Worker interceptera 100 % des requêtes vers example.com — aucun chemin de contournement n’existe (en supposant qu’il n’y ait pas d’autres enregistrements DNS comme un sous-domaine pointant directement vers l’IP Hetzner, ou un cache CDN servant du contenu obsolète devant).
Ce que la réponse a passé sous silence / a mal interprété :
Cache du navigateur : si une réponse précédente (provenant de Hetzner) a été mise en cache avec un TTL long et des en-têtes Cache-Control, le navigateur d’un visiteur revenant pourrait servir une page mise en cache sans même atteindre Cloudflare. Risque mineur, mais réel — il vaut mieux définir Cache-Control: no-store sur la réponse de maintenance.
Cache Cloudflare : si vous avez des règles de cache/règles de page mettant en cache le HTML pour example.com, une copie mise en cache pourrait être servie sans jamais atteindre la logique du Worker, selon l’ordre des règles. Les Workers s’exécutent par défaut avant la recherche de cache dans la plupart des configurations, mais s’il existe une règle de cache définie sur “Cache Everything”, cela peut interagir de manière méritant d’être testée, et non supposée.
Code de statut 503 : utiliser 503 est une bonne pratique (les moteurs de recherche ne désindexeront pas pendant une maintenance brève), mais il devrait ajouter Retry-After correctement formaté — l’exemple le fait correctement.
L’affirmation “sans toucher à la configuration nginx/docker de Discourse” est exacte.
Aucune mention de la latence de lecture KV à l’intérieur du Worker lui-même — négligeable, inférieure à la milliseconde, pas une vraie préoccupation.
En résumé : faisable, et mieux que l’approche nginx. “Instantané” est optimiste — appelez cela “se propage en ~60 secondes dans le monde entier” et dites-leur de tester avec le cache désactivé en premier. La réponse aurait dû signaler le délai de propagation KV au lieu d’impliquer que c’est instantané.
et qui semble être un serveur moins performant… ?
) sera venu.