Compatibilité nginx

bext lit votre nginx.conf existant — chaque bloc include, chaque bloc server et location — et dessert le trafic lui-même. Pas de réécriture de configuration, pas de projet de migration. En mode mascarade, il installe en tant que service nginx, de sorte que les mêmes boîtes qui exécutaient nginx hier exécutent bext aujourd'hui et rien en amont ne le remarque.

En un coup d'œil#

• 68 des 70 directives communes — Couverture à 97 % des directives que les configurations réelles utilisent réellement
• Validé par rapport à des configurations réelles — des centaines de tests d'analyseur et de conversion, exécutés sur des fichiers de production nginx.conf avec des dizaines d'hôtes virtuels
• Aucune modification de configuration — pointez bext sur votre nginx.conf et c'est parti
• apparaît sous la forme nginx — systemctl reload nginx, nginx -t, certbot et logrotate continuent de fonctionner sans changement (Mode mascarade)
• PHP, à votre façon — proxy vers vos pools PHP-FPM existants, ou exécutez PHP dans le runtime intégré de bext et retirez complètement FPM
• Détection automatique WordPress — reconnaît les wp-config.php / wp-content et connecte le routage et la gestion des fichiers statiques
• Suivi des certificats SSL — expiration analysée à partir des fichiers de certificat et apparue dans les tableaux de bord
• Synchronisation cloud — bext nginx sync-cloud pousse chaque hôte virtuel vers le cloud. bext.dev, regroupé par client pour les flottes d'agence

Comment ça marche#

La compatibilité nginx de bext est un pipeline en trois étapes :

1. Parse — Un analyseur à descente récursive lit nginx.conf (y compris toutes les directives include avec expansion globale) et crée un AST
2. Convert — Le convertisseur transforme les directives nginx en configuration de routage interne, de mise en cache, de TLS et de sécurité de bext.
3. Serve — Le serveur HTTP de bext gère tout le trafic à l'aide de la configuration convertie

# Auto-detect nginx.conf and serve
bext serve --nginx-compat

# Or specify a config path
bext serve --nginx-config /etc/nginx/nginx.conf

# Full masquerade — replace nginx entirely
bext nginx masquerade install

Flux de demande#

Lorsqu'une requête arrive en mode compatible nginx, bext la traite via le même pipeline que nginx :

1. Routage d'en-tête d'hôte — faire correspondre la requête à un bloc server {}
2. Règles d'accès — évaluer les directives allow / deny
3. Authentification — vérifiez les informations d'identification auth_basic
4. Limitation de débit — applique les zones limit_req et limit_conn
5. Contrôle de la taille du corps — valider client_max_body_size
6. Conditions — évaluer les blocs if
7. Réécrire les règles — appliquer les directives rewrite et return
8. Emplacement correspondant à — trouvez le bloc location {} le mieux correspondant
9. Pipeline de réponse — proxy, FastCGI, fichier statique ou réponse fixe
10. Sortie — en-têtes, compression gzip, corps de réponse

Fonctionnalités prises en charge#

Types de sites pris en charge#

bext gère tous les types de sites courants trouvés dans les configurations de production nginx :

PHP fonctionne de deux manières et bext sélectionne en fonction de votre configuration :

• Proxy de votre pool PHP-FPM existant — lorsqu'un PHP location a un fastcgi_pass, bext l'honore et le transmet à ce socket ou à cette adresse, exactement comme l'a fait nginx. Il s'agit du véritable chemin d'accès : vos pools FPM, OPcache et votre version PHP sont intacts. La version est lue à partir du nom du socket (par exemple php8.4-fpm.sock → 8.4) pour le reporting.
• Runtime PHP intégré — bext est également livré avec son propre PHP SAPI (mode travailleur, OPcache ; intégré via la fonctionnalité php). Lorsqu'un PHP location correspond mais ne déclare aucun fastcgi_pass, bext exécute PHP en cours, vous permettant de retirer complètement PHP-FPM. Voir Laravel et Micro-framework PHP.

Les actifs statiques (CSS, JS, images) sont toujours servis directement par bext, même sur les sites PHP – correspondant aux blocs location habituels du fichier statique nginx.

Ce qui est différent#

Neuf directives nginx sont intentionnellement et non implémentées car l'architecture de bext les gère automatiquement :

• sendfile, tcp_nopush, tcp_nodelay — gérés par le système d'exploitation et les E/S asynchrones de Rust
• worker_processes, worker_connections — bext utilise des tâches asynchrones, et non des processus de fork
• events {} — non applicable dans un environnement d'exécution asynchrone
• types {} — bext utilise la détection MIME intégrée
• proxy_buffering, proxy_buffer_size — bext diffuse les réponses

Synchronisation dans le cloud#

Synchronisez vos hôtes virtuels nginx avec le tableau de bord bext cloud en tant que projets et domaines — aucune configuration manuelle n'est nécessaire :

bext nginx list                        # List vhosts with stable IDs
bext nginx diff --cloud-api-key $KEY   # Compare nginx vs cloud state
bext nginx sync-cloud --cloud-api-key $KEY   # Push all to cloud
bext nginx sync-cloud --only a282,5427       # Push selected vhosts only

Chaque hôte virtuel obtient un identifiant hexadécimal stable à 4 caractères dérivé de sa liste de domaines. La commande diff classe chacun comme synchronisé, nouveau, dérive (incompatibilité de domaine) ou obsolète (dans cloud mais pas nginx ).

Voir Référence CLI pour tous les indicateurs.

Prochaines étapes#

• Analyseur de configuration — comment fonctionne l'analyseur
• Couverture de la directive — référence complète de la directive
• Guide de migration — migration étape par étape depuis nginx
• Mode mascarade — remplacement complet avec systemd
• API de purge du cache — Gestion du cache compatible nginx
• Tableau de bord de contrôle en amont — interface utilisateur Web pour l'inspection avant migration
• Processus de rachat — migration du trafic atomique avec restauration

En rapport#

• Guide de migration : à partir de nginx — liste de contrôle structurée pour le déplacement d'une flotte
• PHP et PHP-FPM — Répartition FastCGI et runtime PHP intégré
• Intégration WordPress — routage WP détecté automatiquement au-dessus de nginx -compat
• Mise en cache — TTL, périmé pendant la revalidation et garde de bousculade
• TLS et HTTPS — comment bext charge et recharge à chaud les certificats

Links#

• Documentation nginx — référence en amont pour la sémantique des directives