---
title: "Hébergement BungeeCord et Waterfall au Brésil | Proxy hérité"
description: "BungeeCord et Waterfall au Brésil pour les réseaux déjà en production : ce qu’il faut fermer au pare-feu, ce que le fork a changé et le prix réel d’une migration vers Velocity."
url: "https://streethosting.com.br/fr/minecraft-bungeecord"
type: "page"
language: "fr"
---

Proxy hérité, exploité avec discernement

# Hébergement BungeeCord et Waterfall pour un network déjà en ligne

Si votre réseau tourne en BungeeCord ou en Waterfall et que migrer maintenant n’est pas envisageable, la question n’est plus de savoir quel proxy est le meilleur. Elle devient : fermer les bons ports et fixer l’heure du départ.

[Voir les VPS avec root pour le proxy](https://streethosting.com.br/fr/vps-minecraft) [Comparer avec Velocity](https://streethosting.com.br/fr/minecraft-velocity)

* São Paulo, Brésil
* Anti-DDoS jusqu’à 400 Tbit/s
* NVMe

 Réponse rapide

Pour un network neuf, Velocity est le meilleur choix : Waterfall a été abandonné par PaperMC et le forwarding de BungeeCord n’est pas signé. BungeeCord reste défendable quand le réseau est déjà en production avec des plugins de proxy sans équivalent.

## La réponse honnête avant le reste de la page

BungeeCord a porté la première génération de networks brésiliens, et Waterfall est arrivé comme fork de PaperMC : même API, mêmes plugins, correctifs de protocole. PaperMC a déclaré Waterfall abandonné et a recommandé Velocity. Il fonctionne, mais sans développement actif.

Pour un réseau neuf, le moindre regret s’appelle Velocity, et cette page ne prétendra pas le contraire. Presque tout BungeeCord en ligne aujourd’hui est un héritage : joueurs actifs, boutique en service et plugins écrits contre l’API net.md\_5.bungee.

## Le trou que laisse ouvert le forwarding hérité

Ce qui fait tomber un network Bungee, ce n’est pas le lag, c’est l’authentification. Avec ip\_forward activé dans config.yml, le proxy injecte l’IP et l’UUID réels dans le handshake. Pour l’accepter, le backend tourne avec online-mode désactivé et le drapeau bungeecord activé dans spigot.yml.

Ce handshake n’est pas signé : il n’y a aucun secret partagé entre proxy et backend. Quiconque atteint le port d’un backend reconstruit le même paquet et se connecte avec l’UUID de son choix, y compris celui du propriétaire.

Les défenses vont de pair. Côté réseau, des backends qui n’écoutent que sur 127.0.0.1 ou un pare-feu qui n’accepte que l’IP du proxy. Côté application, BungeeGuard, qui couvre le jour où quelqu’un se trompe de règle.

## Quand rester est la bonne décision

Rester se justifie dans trois cas : un plugin de proxy sans équivalent et sans code source ; une saison ouverte, parce que changer le point d’entrée coupe l’accès à tout le monde si cela tourne mal ; et un réseau grand et déjà stable.

Geler la version, documenter la configuration et repousser la migration est une décision légitime. Ce qui ne l’est pas, c’est de découvrir quelle version tourne le jour de l’incident.

## Le coût réel de la migration, poste par poste

La partie chère, c’est le plugin de proxy : l’API de Velocity est autre et rien de Bungee n’y tourne sans portage. Répartissez le dossier plugins en trois piles : version Velocity disponible, remplaçant existant, ou code neuf à écrire. La troisième pile, c’est le budget.

La partie bon marché, c’est le backend, car Velocity conserve le canal hérité de plugin messaging. Ajoutez les permissions, le MOTD, le tab et l’intégration Discord. Montez le nouveau proxy sur un port alternatif et changez le DNS en dernier.

Infrastructure

## Ce que la machine doit apporter à un proxy

* Un vrai root pour le pare-feu, les limites système et l’arbre du proxy, sans panneau au milieu.
* Une IP publique stable, car l’adresse du proxy est celle affichée dans la communication du réseau.
* Un réseau national : chaque changement de serveur traverse deux fois le proxy avant d’atteindre le joueur.

Cas d’usage

## Les réseaux qui restent en Bungee pour de bonnes raisons

* File d’attente, staff ou boutique écrits contre l’API Bungee, sans auteur pour les porter.
* Saison en cours, quand changer le point d’entrée est le plus gros risque.
* Réseau grand et stable, avec la migration prévue pour le changement de map.

Optimisation

## Des réglages qui valent mieux qu’un changement de proxy

* Fermer les backends sur 127.0.0.1 ou derrière un pare-feu avant de choisir un proxy.
* Ajouter BungeeGuard par-dessus le pare-feu, pour qu’une règle mal écrite ne devienne pas un accès admin.
* Séparer proxy et backends sur des instances, pour qu’un monde figé n’emporte pas le login.

 Fiche technique

## Comment dimensionner la machine du proxy

Un proxy n’est pas un backend : la règle de dimensionnement est ici différente.

Où la charge apparaît

Réseau et clock, pas la RAM

Le proxy ne génère aucun chunk et ne fait tourner aucun tick de monde : il décompresse, chiffre et réachemine des paquets. Le goulet, c’est la fréquence par cœur.

Entrée VPS Ryzen Budget

R$ 31,00/mois (2GB, 20GB NVMe, 1 vCPU)

Suffit au proxy d’un petit réseau, avec les backends sur une autre instance.

Entrée VPS Ryzen Performance

R$ 42,00/mois (2GB DDR5, 20GB NVMe, 1 vCPU)

Quand le pic de connexion est concentré et que le login ne doit pas faire la queue.

Protection de bordure

AntiDDoS 400 Tbps

Le proxy est la seule IP publique du réseau : le faire tomber fait tomber tous les backends d’un coup.

 Comparatif

## BungeeCord, Waterfall et Velocity côte à côte

Ce qui les sépare, c’est la maintenance, le modèle de forwarding et le prix du départ.

| Critère                    | BungeeCord                         | Waterfall                                        | Velocity                                  |
| -------------------------- | ---------------------------------- | ------------------------------------------------ | ----------------------------------------- |
| Maintenance                | Actif, à rythme lent               | Abandonné par PaperMC                            | Actif, c’est là que l’écosystème investit |
| API de plugin              | net.md\_5.bungee                   | La même que BungeeCord                           | com.velocitypowered.api, incompatible     |
| Forwarding                 | Hérité, sans signature             | Hérité, avec BungeeGuard en rustine              | Moderne, signé par secret partagé         |
| Si un backend reste exposé | Connexion sous n’importe quel UUID | Pareil, sauf si le token est actif               | Connexion refusée faute de signature      |
| Indiqué pour               | Un réseau hérité en production     | Un réseau hérité qui veut les correctifs du fork | Tout nouveau projet                       |

Si la colonne du milieu décrit votre réseau, vous n’êtes pas dans l’erreur. Vous êtes sur un logiciel sans maintenance active, un risque gérable avec les backends fermés et une date de sortie.

## Questions fréquentes

01 BungeeCord est-il encore sûr en 2026 ?

Il est sûr dans la mesure où vous fermez les backends. Le forwarding n’est pas signé, donc quiconque atteint le port d’un backend entre avec l’UUID de son choix. Avec 127.0.0.1 ou un pare-feu et BungeeGuard, le réseau tient.

02 Waterfall a été abandonné. Dois-je migrer tout de suite ?

Pas tout de suite, mais avec une date fixée. Sans développement actif, une nouvelle faille de protocole peut ne jamais être corrigée. Gelez la version et planifiez la sortie pour le prochain changement de saison.

03 Mes plugins BungeeCord fonctionnent-ils sur Velocity ?

Ceux du proxy, non : l’API est autre et chacun réclame une version Velocity, un remplaçant ou un portage. Ceux des backends survivent en général, car Velocity conserve le canal de plugin messaging.

04 Peut-on faire tourner le proxy et les backends sur le même VPS ?

Oui, et pour un petit réseau c’est l’arrangement le plus simple : les backends écoutent sur 127.0.0.1 et restent inaccessibles de l’extérieur. La limite apparaît quand un backend se fige et emporte le login avec lui.

 Poursuivez ici

## Des lectures d’appui pour qui exploite un network

* [Velocity et BungeeCord : quand utiliser un proxy La comparaison complète et le moment où un réseau a vraiment besoin d’un proxy.](https://streethosting.com.br/fr/guias/minecraft/velocity-bungeecord-rede-servidores)
* [Pare-feu UFW sur un VPS Ubuntu Des règles qui bloquent l’accès direct aux backends sans couper le SSH.](https://streethosting.com.br/fr/guias/vps/firewall-ufw-vps-ubuntu)
* [Paper sur un VPS avec root, de zéro Chaque backend avec son service, un utilisateur dédié et un redémarrage automatique.](https://streethosting.com.br/fr/guias/vps/hospedar-paper-minecraft-vps-root-guia)
* [Migrer un serveur sans downtime Faire tourner le nouvel environnement en parallèle et basculer le DNS en dernier.](https://streethosting.com.br/fr/guias/infraestrutura/como-migrar-servidor-sem-downtime)

4.7/5 sur Trustpilot

Satisfait ou remboursé

Activation en 60 s

Support Premium

Approuvé par plus de 2 500 clients

## Ce que nous réglons avec vous avant de toucher au proxy

* Lecture de la topologie actuelle : combien de backends existent et qui parle à qui.
* Fermeture des ports des backends et test depuis l’extérieur avant de basculer.
* Fenêtre de maintenance avec l’ancien proxy debout jusqu’à ce que le nouveau passe.

[Voir les VPS avec root pour le proxy](https://streethosting.com.br/fr/vps-minecraft) [Contacter le support](https://streethosting.com.br/fr/contact)

Un réseau hérité n’a pas besoin d’un nouveau discours. Il a besoin de backends fermés, d’une version notée et d’une date pour migrer.
