« Host ‘X’ is not allowed to connect to this MySQL server »
Ce que ça signifie : le client MySQL rejette la connexion avec exactement ce message. Pourquoi ça arrive : les bases de données hébergées par Square Cloud exigent SSL pour chaque connexion. Cette erreur apparaît quand la connexion est tentée sans le certificat chargé, et non à cause d’un pare-feu/liste blanche d’hôtes comme le message le laisse penser. Comment corriger :- Ouvrez la base de données dans le tableau de bord Square Cloud et téléchargez les fichiers de certificat (CA, cert, key, généralement 2-3 champs).
- Chargez-les dans la configuration SSL/TLS de votre client :
- Clients GUI (MySQL Workbench, DBeaver, HeidiSQL) : configurez les fichiers de certificat téléchargés dans l’onglet SSL du client, puis connectez-vous avec l’hôte/port/utilisateur/mot de passe affichés dans le tableau de bord.
- Code (Prisma ORM) : convertissez le certificat client + la clé en
.p12:Puis définissez :Livrezclient.p12dans le zip de l’application et définissezDATABASE_URLdans les variables d’environnement de l’application, puis redémarrez-la.
- Vérifiez que le nom d’utilisateur et le mot de passe correspondent à ceux affichés dans le tableau de bord, et redémarrez la base de données si le certificat vient juste d’être généré.
MongoNetworkError et échecs de liste blanche IP MongoDB Atlas
Ce que ça signifie : un cluster MongoDB Atlas hébergé en externe (pas une base de données gérée Square Cloud) refuse la connexion avecMongoNetworkError: connection ... closed, même si les identifiants sont corrects.
Pourquoi ça arrive : les conteneurs d’applications Square Cloud utilisent une adresse IPv4 dynamique qui change à chaque redémarrage. Une liste blanche IP MongoDB Atlas configurée pour une seule IP statique fonctionnera jusqu’au prochain redémarrage, puis échouera silencieusement.
Comment corriger, au choix :
- Recommandé si vous avez besoin d’Atlas externe : dans Atlas → Network Access, ajoutez
0.0.0.0/0pour autoriser les connexions depuis n’importe quelle IP, et compensez la liste blanche élargie par des identifiants forts (mot de passe long et aléatoire, utilisateur de base de données dédié, chaîne de connexion conservée uniquement dans des variables d’environnement). Voir aussi MongoDB Atlas avec une IP dynamique. - Recommandé globalement : déplacez la base de données vers une base de données gérée Square Cloud au lieu d’un cluster Atlas externe. Héberger la base de données à côté de l’application élimine entièrement le problème de liste blanche IP et offre une latence quasi nulle.
Délai de connexion et ECONNREFUSED
Ce que ça signifie : l’application reste bloquée jusqu’au délai d’attente, ou échoue immédiatement avecECONNREFUSED, en essayant d’atteindre une base de données.
Pourquoi ça arrive, en règle générale :
- Un délai d’attente (la connexion reste bloquée, pas de rejet immédiat) signifie généralement qu’un pare-feu ou une liste blanche IP sur la base de données de destination bloque la connexion. De nombreux fournisseurs externes bloquent par défaut les IP de datacenter/étrangères.
- Un ECONNREFUSED immédiat ou une « authentification échouée » signifie généralement que l’hôte/port est joignable mais que les identifiants, le nom de la base de données, ou le numéro de port sont incorrects.
- Si vous vous connectez à un fournisseur externe (pas une base de données gérée Square Cloud), autorisez les ASN de Square Cloud sur le pare-feu de destination :
398395et26548. Là où seule la liste blanche par IP est prise en charge (comme MongoDB Atlas), utilisez0.0.0.0/0avec des identifiants forts à la place, puisque l’IP source est dynamique. - Vérifiez l’hôte, le port, le nom d’utilisateur et le mot de passe par rapport à ce qu’affiche le fournisseur ou le tableau de bord Square Cloud.
- Encodez en URL tout caractère spécial dans la chaîne de connexion (
@,:,/, etc. dans un mot de passe cassera l’analyse s’il est laissé brut). - Vérifiez si le pilote du fournisseur nécessite un paramètre
ssl=trueexplicite (ou similaire) dans la chaîne de connexion.
Erreurs de connexion SSL/TLS
Ce que ça signifie : le client échoue à établir une poignée de main TLS avec la base de données, ou échoue juste après avec une erreur qui ressemble à un problème d’authentification mais est en réalité un problème de certificat. Pourquoi ça arrive : les bases de données gérées Square Cloud exigent SSL pour chaque connexion. Chaque moteur de base de données attend le certificat sous une forme légèrement différente :- Redis : le protocole doit être
rediss://(deux s), jamaisredis://. Forme :rediss://default:PASSWORD@HOST:PORT.node-redisaccepte aussisocket: { tls: true, ca: fs.readFileSync("certificate.pem") }; la bibliothèque Pythonredisprendssl_ca_certs/ssl_certfile/ssl_keyfile(lecertificate.pemcombiné téléchargé depuis le tableau de bord fonctionne pour tous). - Drizzle ORM (Postgres) : un
Poolpgstandard avecssl: { ca, cert, key }, tous chargés viafs.readFileSyncdepuis lecertificate.pemcombiné, et le même objetssldansdrizzle.config.ts. - JDBC (Java) : la clé du client doit être convertie au format PK8/DER et référencée dans les propriétés SSL de l’URL JDBC.
Guides associés
- Créer une base de données managée et s’y connecter : la configuration complète, avec des exemples de connexion.
- Bases de données : moteurs, versions et ce que comprend chaque plan.
- Variables d’environnement : garder la chaîne de connexion hors de votre code.
- Problèmes de connexion, pare-feu et blocages d’IP dans le centre d’aide.

