Pourquoi votre cloud privé fonctionne-t-il en Wi-Fi mais échoue en données mobiles ?

Un cloud privé peut fonctionner parfaitement sur le Wi-Fi domestique et échouer sur les données mobiles. Cela ne signifie généralement pas que l'application de cloud privé est défectueuse. Cela signifie que votre téléphone utilise un chemin réseau différent.

À la maison, le téléphone peut atteindre une adresse IP locale, un nom d'hôte local ou un service de découverte uniquement LAN. Sur données mobiles, le téléphone doit atteindre votre cloud privé via un domaine public, une IP publique, un VPN, un tunnel ou un autre chemin d'accès distant. Si le DNS, le routage, les certificats, les domaines de confiance, les règles du pare-feu ou le comportement de l'opérateur sont incorrects, le Wi-Fi fonctionne tandis que les données mobiles échouent.

Le Wi-Fi et les données mobiles atteignent votre cloud privé de manières différentes

Le symptôme est familier : votre application de cloud privé fonctionne sur le Wi-Fi domestique, la sauvegarde photo s'exécute normalement, la synchronisation de fichiers se connecte, et l'interface web s'ouvre depuis votre téléphone. Puis vous passez en 5G ou LTE et vous voyez un délai d'attente, une impossibilité de connexion, un échec de connexion, une erreur de certificat, ou une application qui tourne en boucle.

En Wi-Fi, votre téléphone et le cloud privé sont dans le même LAN. La connexion peut utiliser une adresse locale telle que 192.168.1.50, un nom d'hôte local ou une découverte automatique. Sur données mobiles, votre téléphone est sur le réseau de l'opérateur. Il doit atteindre votre serveur domestique par un chemin distant, pas par la même route locale.

Le succès sur Wi-Fi prouve seulement que le chemin local fonctionne. L'échec sur données mobiles signifie que le chemin externe est manquant, bloqué, mal configuré ou incompatible avec le réseau mobile. Le dépannage doit séparer l'accès interne de l'accès externe au lieu de les traiter comme une seule connexion.

L'application peut utiliser une adresse locale qui ne fonctionne qu'à la maison

La cause la plus courante est aussi la plus simple. L'application de cloud privé peut être enregistrée avec une URL telle que http://192.168.1.50:8080, https://cloud.local, https://nas.local, ou un nom d'appareil attribué par le routeur. Ces adresses peuvent fonctionner à la maison mais échouer partout ailleurs.

Les plages IPv4 privées telles que 10.x.x.x, 172.16–31.x.x et 192.168.x.x sont destinées aux réseaux privés. Une adresse privée locale uniquement n'est pas une destination publique sur Internet, donc votre téléphone ne peut pas y accéder directement lorsqu'il utilise les données mobiles.

Si l'application mobile utilise une URL accessible uniquement sur le réseau local (LAN), ne commencez pas par modifier au hasard les paramètres du pare-feu. Décidez d'abord si l'accès mobile doit passer par un domaine public, un VPN ou un VPN maillé, ou un tunnel. Sans l'un de ces chemins, le téléphone essaie d'atteindre une adresse qui n'existe qu'à l'intérieur de votre maison.

L'URL interne et l'URL externe sont souvent confondues

Beaucoup de configurations de cloud privé finissent avec deux identités. L'URL interne fonctionne à la maison, comme http://192.168.1.50:8080. L'URL externe est censée fonctionner depuis l'extérieur, comme https://cloud.example.com ou un nom d'hôte de tunnel.

Ces deux noms peuvent pointer vers le même service, mais ce n'est pas le même mode d'accès. L'URL interne peut utiliser une IP privée, un DNS local ou un certificat auto-signé. L'URL externe peut nécessiter un DNS public, HTTPS, un proxy inverse, un transfert de port, un routage VPN ou un tunnel.

Les problèmes apparaissent lorsque les favoris, applications mobiles, clients de synchronisation et raccourcis de navigateur mélangent ces identités. Pour les données mobiles, utilisez l'URL externe si le service est censé être accessible depuis l'extérieur. Si vous souhaitez tout garder privé, connectez-vous d'abord via VPN puis utilisez l'adresse LAN.

Le DNS peut se résoudre correctement en Wi-Fi mais échouer en cellulaire

Un domaine peut fonctionner à la maison et échouer en données mobiles parce que le téléphone interroge un système DNS différent. À la maison, votre routeur, Pi-hole, AdGuard Home ou serveur DNS local peut résoudre cloud.example.com vers une IP interne. En données mobiles, le DNS de l'opérateur ou un DNS public peut renvoyer une réponse différente ou aucune réponse du tout.

C'est courant dans les configurations DNS fractionnées. À l'intérieur du LAN, le domaine pointe vers l'adresse privée pour la rapidité et la simplicité. À l'extérieur du LAN, il doit pointer vers une IP publique, un nom accessible via VPN ou un point de terminaison de tunnel. Si l'enregistrement externe est manquant ou obsolète, le téléphone ne peut pas trouver le service.

Ne supposez pas qu'un domaine est correct simplement parce qu'il fonctionne en Wi-Fi. Testez le même domaine en données mobiles et confirmez où il se résout. Si les résultats DNS internes et externes sont intentionnellement différents, documentez cette conception pour que les paramètres de l'application n'utilisent pas accidentellement le mauvais nom.

Les domaines de confiance, les URL de base et les proxies inverses peuvent refuser l'accès mobile

Parfois, la requête mobile atteint le serveur, mais l'application échoue quand même. Vous pouvez voir un avertissement de domaine non fiable, une erreur d'hôte invalide, un échec de connexion, une boucle de redirection ou un problème de synchronisation WebDAV. Cela signifie généralement que le chemin a atteint le cloud privé, mais que l'application ne fait pas confiance au nom ou aux en-têtes proxy reçus.

Le logiciel de cloud privé nécessite souvent des réglages explicites de nom d'hôte et d'URL. La référence de configuration de Nextcloud inclut les paramètres de domaine de confiance et d'URL de base, et sa documentation sur le proxy inverse couvre la détection d'URL de proxy inverse lorsque la détection automatique du nom d'hôte, du protocole ou du chemin web échoue.

Si les données mobiles chargent la page de connexion mais que la connexion, les redirections, la synchronisation ou les liens de partage échouent, vérifiez la configuration de l'application. Le nom d'hôte externe doit être fiable, l'URL publique doit correspondre à ce que les utilisateurs saisissent, les en-têtes proxy doivent être corrects, et les redirections HTTP vers HTTPS ne doivent pas renvoyer l'application vers une adresse LAN privée.

Les certificats HTTPS révèlent souvent une mauvaise conception d'accès

L'accès Wi-Fi peut fonctionner avec un certificat auto-signé, un nom d'hôte interne ou un avertissement du navigateur que vous avez accepté manuellement il y a des mois. Les applications mobiles peuvent être plus strictes, surtout lors de la synchronisation de fichiers, photos, calendriers ou données WebDAV en arrière-plan.

Les certificats HTTPS sont liés aux noms. Si l'application se connecte à 192.168.1.50, cloud.local, ou un nom d'hôte différent de celui du certificat, les clients mobiles peuvent rejeter la connexion. Si un proxy inverse modifie incorrectement le nom d'hôte ou le protocole, l'application peut aussi échouer après la connexion.

Une configuration externe propre utilise un domaine public stable avec un certificat valide et une configuration de proxy inverse correspondante. Une configuration privée propre utilise d'abord un VPN ou VPN maillé, puis un accès interne. Mélanger adresses IP, noms locaux, noms publics et certificats non assortis rend l'accès mobile peu fiable.

Le transfert de port, le VPN ou le tunnel doivent fournir le chemin mobile

Un cloud privé ne devient pas automatiquement accessible depuis les données mobiles simplement parce qu'il fonctionne en Wi-Fi. Le trafic extérieur nécessite un chemin intentionnel vers le réseau domestique ou vers le point de service.

Il existe trois schémas courants. Le transfert de port envoie un trafic public spécifique à travers le routeur vers le cloud privé. Un VPN ou VPN maillé permet au téléphone de rejoindre d'abord un réseau privé. Un tunnel inverse permet au serveur de créer une connexion sortante vers un point d'accès public, puis les appareils mobiles se connectent via ce point.

Pour un accès personnel à un cloud privé, un VPN ou un VPN maillé est généralement le premier choix le plus sûr. Pour partager un service directement avec d'autres, un domaine public avec HTTPS, un proxy inverse et un contrôle d'accès rigoureux peuvent être appropriés. Pour le CGNAT ou les routeurs verrouillés, un tunnel peut être plus pratique que le transfert de port.

Le CGNAT peut faire paraître le transfert de port correct mais échouer quand même

Le CGNAT est frustrant car la configuration domestique peut sembler correcte. Le cloud privé fonctionne en Wi-Fi. Le pare-feu du serveur autorise le port. Le routeur a une règle de transfert. Mais les données mobiles ne peuvent toujours pas atteindre le service.

Le problème est que votre routeur peut ne pas avoir une vraie adresse IPv4 publique. La RFC 6598 réserve 100.64.0.0/10 comme espace d’adresses partagé utilisé pour CGNAT. Lorsque votre ISP place votre routeur derrière un NAT de niveau opérateur, le trafic externe peut ne jamais atteindre votre routeur domestique, donc votre règle de transfert de port n’a rien à rediriger.

Comparez l’IP WAN affichée sur votre routeur avec l’IP publique affichée par un site externe de vérification d’IP. Si elles ne correspondent pas, ou si l’adresse WAN appartient à des plages partagées ou privées, le transfert de port classique est probablement une mauvaise solution. Utilisez une option d’IP publique fournie par l’ISP, un VPN maillé ou un tunnel inverse à la place.

Les réseaux mobiles peuvent ajouter des problèmes spécifiques à IPv6 et aux opérateurs

Certains problèmes apparaissent uniquement sur les données mobiles. Le même cloud privé peut fonctionner depuis un autre réseau Wi-Fi mais échouer en 5G ou LTE. Ou un opérateur fonctionne tandis qu’un autre ne fonctionne pas. Cela indique un problème au-delà du routeur domestique.

Les réseaux mobiles peuvent utiliser des conceptions IPv6-only, NAT64, CGNAT, DNS opérateur, politiques APN, filtrage ou comportement proxy. Les recommandations d’Apple sur la compatibilité réseau mobile IPv6-only rappellent que les réseaux mobiles ne se comportent pas comme un LAN domestique dual-stack normal, surtout si une application ou un serveur suppose un comportement IPv4-only.

Si les données mobiles sont le seul chemin qui échoue, testez plusieurs angles. Essayez la même URL dans un navigateur mobile, testez un autre opérateur ou point d’accès, vérifiez les enregistrements DNS A et AAAA, confirmez si le serveur supporte la famille d’adresses utilisée, et essayez un VPN sur les données mobiles. Si le VPN fonctionne, le cloud privé lui-même est probablement correct ; le problème vient du chemin mobile public.

Les applications mobiles peuvent se comporter différemment des navigateurs

Un navigateur sur téléphone et une application mobile ne se comportent pas toujours de la même manière. Le navigateur peut ouvrir la page de connexion, tandis que l’application ne parvient pas à se synchroniser. Ou l’application peut fonctionner en Wi-Fi parce qu’elle découvre le serveur localement, mais échouer en données mobiles car la découverte n’est plus disponible.

Les applications mobiles peuvent mettre en cache une ancienne URL de serveur, exiger HTTPS, rejeter les certificats non conformes, utiliser un point d'accès WebDAV ou API différent de la page du navigateur, restreindre les données en arrière-plan ou suivre les redirections différemment. Certaines applications stockent aussi des adresses de serveur internes et externes séparées sans que cela soit évident.

Testez toujours les deux chemins. Ouvrez l'URL externe dans le navigateur du téléphone en données mobiles, puis testez l'application. Si le navigateur échoue aussi, le problème vient probablement du DNS, du routage, du TLS, du CGNAT ou de la configuration du tunnel. Si le navigateur fonctionne mais pas l'application, concentrez-vous sur les paramètres d'URL de l'application, les domaines de confiance, les certificats, les chemins WebDAV/API et le cache de l'application.

Le VPN ou VPN maillé résout souvent le problème en restaurant le chemin LAN

Si le cloud privé fonctionne en Wi-Fi mais pas en données mobiles, un VPN peut être une solution propre car il change la position du téléphone. Au lieu d'atteindre le cloud privé comme un client extérieur aléatoire, le téléphone rejoint d'abord un réseau privé.

Les outils VPN maillés peuvent utiliser des chemins directs ou relais selon les réseaux impliqués. Tailscale documente l'accès privé via connexions directes ou relayées, ce qui est un contexte utile lorsqu'un appareil mobile doit atteindre un serveur domestique sans exposer directement le cloud privé à internet.

Pour un accès personnel, c'est généralement le modèle le moins déroutant. L'application peut utiliser l'adresse LAN interne ou un nom DNS privé après la connexion VPN. Le cloud privé reste hors de l'internet ouvert, et l'appareil mobile s'authentifie avant d'accéder aux services internes.

Les tunnels inverses sont utiles lorsque vous avez besoin d'une URL externe sans ouvrir de ports

Un tunnel inverse est utile lorsque vous ne pouvez pas ou ne souhaitez pas ouvrir de ports entrants sur votre routeur. Cela est courant avec le CGNAT, les routeurs ISP verrouillés, l'internet en appartement, ou pour les utilisateurs qui préfèrent ne pas exposer directement le routeur domestique.

Cloudflare Tunnel utilise un tunnel sortant pour accès à distance, où le connecteur à l'intérieur de votre réseau initie la connexion vers l'extérieur. Les appareils mobiles accèdent ensuite à un nom d'hôte public qui redirige via le tunnel.

Cela peut faciliter l'accès aux données mobiles, mais cela doit toujours être configuré avec soin. Utilisez des politiques d'accès, HTTPS, une exposition de service limitée, et séparez les interfaces d'administration des services publics destinés aux utilisateurs. Un tunnel résout la question de la connectivité ; il ne résout pas automatiquement les permissions ou la configuration de l'application.

Un ordre pratique pour le dépannage

Ce problème devient compliqué lorsque DNS, règles du routeur, certificats, paramètres d’application et réseaux mobiles changent tous en même temps. Une meilleure approche est de tester une couche à la fois.

Commencez par noter l’URL exacte qui fonctionne en Wi-Fi. Décidez s’il s’agit d’une IP privée, d’un nom d’hôte local ou d’un domaine public. Puis désactivez le Wi-Fi et testez la même URL sur données mobiles. Ensuite, testez le domaine public prévu, vérifiez le DNS public, comparez l’IP WAN du routeur avec l’IP publique, confirmez si vous utilisez un transfert de port, un VPN ou un tunnel, puis vérifiez le certificat TLS et les paramètres de domaine de confiance.

Le résultat pointe généralement vers la couche concernée. Si navigateur et application échouent tous deux, concentrez-vous sur le DNS, le chemin public, le CGNAT, le certificat ou le tunnel. Si le navigateur fonctionne mais pas l’application, concentrez-vous sur la configuration de l’application, les domaines de confiance, les points d’accès WebDAV/API, les redirections et les URL serveur en cache. Si le VPN sur données mobiles fonctionne, le cloud privé est sain ; le problème vient du chemin externe.

Le choix le plus sûr par défaut est un modèle clair d’accès à distance

L’accès au cloud privé devient peu fiable lorsqu’il y a trop d’entrées à moitié fonctionnelles : une IP LAN, un nom d’hôte local, un nom DDNS, une URL de tunnel, une ancienne URL d’application, un nom d’hôte de proxy inverse, et un favori que personne ne se souvient d’avoir créé.

Choisissez un modèle principal. Pour l’accès personnel, le local uniquement plus VPN est souvent la solution la plus propre. Pour un accès direct à l’application depuis l’extérieur, utilisez un domaine public unique, un HTTPS valide, des paramètres de domaine de confiance corrects, et un proxy inverse sécurisé ou un tunnel. Pour le CGNAT, utilisez un tunnel ou un VPN maillé plutôt que de lutter contre le transfert de port.

Moins vous maintenez de points d'entrée, plus la configuration du téléphone devient simple. Un cloud privé ne devrait pas nécessiter une URL mystérieuse différente pour chaque réseau. Un nom stable, des certificats correspondants et une méthode d'accès claire sont ce qui permet au Wi-Fi et aux données mobiles de fonctionner de manière cohérente.

Conclusion finale

Si votre cloud privé fonctionne en Wi-Fi mais échoue sur les données mobiles, le cloud privé lui-même peut être correct. Le Wi-Fi utilise un chemin local. Les données mobiles nécessitent un chemin distant. L'échec est généralement causé par une URL locale uniquement, un décalage DNS, un transfert de port manquant, un VPN ou tunnel, CGNAT, un décalage de certificat TLS, une configuration de domaine de confiance, un comportement IPv6/IPv4 ou des différences d'application mobile.

Commencez par vérifier quelle URL l'application utilise, si cette URL est locale ou publique, si le DNS public résout, si le routeur a une IP publique réelle, et si HTTPS et les domaines de confiance correspondent au nom externe. Pour un accès personnel, le VPN ou mesh VPN est généralement la solution la plus propre. Pour un accès externe direct, utilisez un domaine public cohérent, un certificat valide et un chemin sécurisé avec soin.

Un NAS cloud privé fiable peut héberger des fichiers, photos, synchronisation, sauvegardes et services d'accès à distance, mais l'accès via les données mobiles dépend toujours du chemin réseau, du domaine, du certificat et de la configuration de l'application.

FAQ

Pourquoi mon cloud privé fonctionne-t-il en Wi-Fi mais pas sur les données mobiles ?

Le Wi-Fi utilise votre réseau local, où les adresses IP privées et les noms d'hôtes locaux peuvent fonctionner. Les données mobiles utilisent le réseau de l'opérateur, donc il faut un domaine public, un VPN, un tunnel ou un autre chemin d'accès externe.

Puis-je utiliser 192.168.x.x sur les données mobiles ?

Non. Un 192.168.x.x l'adresse est privée et ne fonctionne que dans votre réseau local. Pour l'utiliser via les données mobiles, connectez-vous d'abord à votre réseau domestique via VPN ou mesh VPN.

Pourquoi mon domaine fonctionne-t-il à la maison mais pas sur le réseau cellulaire ?

Votre Wi-Fi domestique peut utiliser un DNS local qui pointe le domaine vers une IP privée. Sur le réseau cellulaire, le téléphone utilise un DNS public ou opérateur, qui peut ne pas avoir le même enregistrement ou pointer vers une mauvaise destination.

Pourquoi le navigateur fonctionne-t-il mais pas l'application mobile ?

L'application peut utiliser une API ou un chemin WebDAV différent, mettre en cache une ancienne URL, exiger un domaine de confiance, rejeter un certificat ou gérer les redirections différemment du navigateur.

Le CGNAT affecte-t-il l'accès au cloud privé depuis les données mobiles ?

Oui. Si votre fournisseur d'accès internet domestique utilise CGNAT, le transfert de port peut ne jamais atteindre votre routeur. Dans ce cas, utilisez une option d'IP publique, un VPN/mesh VPN ou un tunnel inverse.

L'IPv6 peut-il causer des problèmes d'accès via les données mobiles ?

Cela peut être le cas. Certains réseaux mobiles utilisent uniquement IPv6 ou privilégient IPv6. Si votre domaine, application ou serveur domestique est uniquement IPv4 ou a des enregistrements DNS incorrects, les données mobiles peuvent se comporter différemment du Wi-Fi.

Le VPN est-il meilleur que l'ouverture de ports pour un cloud privé ?

Pour un accès personnel, généralement oui. Le VPN ou le mesh VPN maintient le cloud privé hors d'internet ouvert et permet aux appareils de confiance d'y accéder comme s'ils étaient sur le réseau local domestique.

Que devrais-je vérifier en premier ?

Vérifiez l'URL enregistrée dans l'application. Si c'est une IP locale ou .local nom d'hôte, cela ne fonctionnera pas sur les données mobiles à moins d'utiliser un VPN. Ensuite, vérifiez le DNS public, CGNAT, HTTPS, les domaines de confiance et les paramètres de l'application.