On tente d’accéder à Sharecloudy, la page ne charge pas, et le navigateur affiche un message vague du type « ERR_CONNECTION_REFUSED » ou reste bloqué sans réponse. Le réflexe habituel consiste à vérifier sa connexion internet, mais quand le reste du web fonctionne normalement, le pare-feu est souvent la cause invisible du blocage. Identifier cette piste précise demande quelques vérifications ciblées qu’on détaille ici.
Blocage silencieux du pare-feu : pourquoi Sharecloudy est visé
Les pare-feu, qu’ils soient intégrés à Windows Defender, à une suite de sécurité tierce ou au routeur d’entreprise, appliquent des règles sur les connexions sortantes. Depuis quelques années, les mises à jour de ces logiciels ajoutent parfois des règles automatiques qui bloquent certains domaines cloud sans prévenir l’utilisateur.
Sharecloudy utilise des ports et des domaines spécifiques pour établir la connexion. Si une règle de filtrage classe ces domaines comme non fiables ou inconnus, la connexion est refusée en amont, avant même que le navigateur puisse afficher une page d’erreur explicite. On se retrouve face à un écran vide ou à un message « connexion refusée » qui ne mentionne jamais le pare-feu.
Ce type de blocage silencieux se distingue d’une panne serveur ou d’un problème DNS par un point simple : le reste de la navigation web fonctionne sans aucun souci.
Test rapide : différencier un blocage pare-feu d’un autre problème réseau
Avant de modifier quoi que ce soit, on a besoin de confirmer que le pare-feu est bien en cause. Voici la séquence de vérification la plus directe.
Désactiver temporairement le pare-feu Windows
Sur Windows, on ouvre les paramètres de sécurité, section « Pare-feu et protection du réseau ». On désactive le pare-feu sur le profil réseau actif (privé ou public). Ensuite, on retente l’accès à Sharecloudy immédiatement.
Si la page se charge, la cause est confirmée. On réactive le pare-feu aussitôt et on passe à la création d’une règle d’exception (détaillée plus bas). Si rien ne change, le problème vient d’ailleurs.
Tester depuis un autre réseau ou en partage de connexion mobile
Quand on est sur un réseau d’entreprise avec un proxy ou un VPN actif, le blocage peut venir du pare-feu du réseau, pas du poste. La méthode la plus rapide : basculer sur un partage de connexion 4G/5G depuis un téléphone. Si Sharecloudy redevient accessible sur l’IP du FAI mobile, le filtrage se situe au niveau du réseau d’entreprise ou du VPN.
Ce scénario est devenu courant, car de nombreux proxys d’entreprise appliquent une politique de refus par défaut sur les domaines cloud qu’ils ne reconnaissent pas explicitement.
Erreur ERR_CONNECTION_REFUSED et Sharecloudy : lire le message du navigateur
Le message d’erreur affiché par Chrome ou Firefox donne des indices exploitables, à condition de savoir les lire.
- ERR_CONNECTION_REFUSED : le serveur distant (ou un équipement intermédiaire comme le pare-feu) a activement rejeté la tentative de connexion. C’est le signal le plus fréquent d’un blocage pare-feu sur Sharecloudy.
- ERR_TIMED_OUT : la requête n’a reçu aucune réponse dans le délai imparti. Cela peut indiquer un pare-feu qui « drop » les paquets sans les rejeter, ou un problème de routage réseau plus large.
- ERR_NAME_NOT_RESOLVED : le navigateur ne trouve pas l’adresse IP associée au domaine. Ici, le problème est DNS, pas pare-feu. On vérifie alors la configuration DNS du poste ou du routeur.
Si on obtient ERR_CONNECTION_REFUSED uniquement sur Sharecloudy et que tous les autres sites fonctionnent, la probabilité d’un filtrage pare-feu est très élevée.
Créer une exception pare-feu pour Sharecloudy sur Windows
Une fois le blocage confirmé, on ajoute une règle d’autorisation plutôt que de laisser le pare-feu désactivé. La manipulation passe par le Pare-feu Windows Defender avec fonctions avancées de sécurité.
Règle sortante dans le pare-feu Windows
On ouvre « wf.msc » depuis la barre de recherche Windows, puis on clique sur « Règles de trafic sortant » dans le panneau de gauche. On crée une nouvelle règle en sélectionnant « Programme » si on utilise un client Sharecloudy dédié, ou « Port » si l’accès se fait via le navigateur.
Pour un accès web classique, on autorise les ports TCP 443 (HTTPS) et éventuellement 80 (HTTP). On nomme la règle de façon explicite (par exemple « Sharecloudy – accès HTTPS ») pour la retrouver facilement plus tard.
Cas des suites de sécurité tierces
Si on utilise un antivirus avec son propre pare-feu (Kaspersky, Bitdefender, Norton, etc.), la règle Windows ne suffit pas toujours. Ces suites interceptent le trafic réseau avant le pare-feu système. On doit ajouter une exception dans les paramètres réseau ou « contrôle des applications » de la suite concernée.
Les retours varient sur ce point selon les versions et les éditeurs, mais la logique reste la même : identifier la section qui gère le filtrage web et y ajouter le domaine Sharecloudy en liste blanche.
Pare-feu d’entreprise ou VPN : quand la solution n’est pas sur votre poste
Dans un contexte professionnel, le filtrage ne dépend souvent pas de la machine locale. Le proxy d’entreprise ou le VPN corporate applique ses propres règles de filtrage, et Sharecloudy peut être bloqué côté serveur proxy sans qu’aucune manipulation locale ne change quoi que ce soit.
Le signe distinctif : Sharecloudy est inaccessible quand le VPN est actif, mais redevient accessible dès qu’on se déconnecte du VPN et qu’on utilise la connexion FAI directe. Dans ce cas, la seule solution passe par l’administrateur réseau, qui doit ajouter le domaine Sharecloudy dans la liste des destinations autorisées du pare-feu ou du proxy.
Pour faciliter cette demande, on prépare les informations utiles : le domaine exact de Sharecloudy, le port utilisé (443 en HTTPS), et une capture d’écran du message d’erreur obtenu. Cela accélère le traitement par l’équipe IT.
Vérifier le DNS avant de conclure à un problème de pare-feu
Un dernier piège courant : confondre un blocage DNS avec un blocage pare-feu. Si le domaine Sharecloudy ne se résout pas correctement, le navigateur affiche une erreur qui peut ressembler à un refus de connexion.
On ouvre une invite de commandes et on tape nslookup suivi du domaine Sharecloudy. Si la commande renvoie une adresse IP valide, le DNS fonctionne et le problème se situe bien au niveau du pare-feu ou du réseau. Si elle échoue, on change de serveur DNS (par exemple en utilisant ceux de Google : 8.8.8.8 et 8.8.4.4) et on reteste.
Cette vérification prend moins d’une minute et évite de passer du temps à modifier des règles de pare-feu pour un problème qui n’en est pas un. Le diagnostic fiable repose sur cette distinction : résolution DNS réussie mais connexion refusée égale pare-feu, résolution DNS échouée égale configuration DNS à corriger.
