Waarom werkt je private cloud op wifi maar niet op mobiele data?

Een private cloud kan perfect werken op thuis-Wi-Fi en toch falen op mobiele data. Dat betekent meestal niet dat de private cloud-app kapot is. Het betekent dat je telefoon een ander netwerkpad gebruikt.

Thuis kan de telefoon een lokaal IP-adres, een lokale hostnaam of een alleen-LAN-ontdekkingsdienst bereiken. Op mobiele data moet de telefoon je private cloud bereiken via een openbaar domein, openbaar IP, VPN, tunnel of een ander extern toegangspad. Als DNS, routering, certificaten, vertrouwde domeinen, firewallregels of providerinstellingen verkeerd zijn, werkt Wi-Fi terwijl mobiele data faalt.

Wi-Fi en mobiele data bereiken je private cloud op verschillende manieren

Het symptoom is bekend: je private cloud-app werkt op thuis-Wi-Fi, fotoback-up draait normaal, bestandsynchronisatie maakt verbinding en de webinterface opent vanaf je telefoon. Dan schakel je over naar 5G of LTE en zie je time-out, kan geen verbinding maken, inloggen mislukt, certificaatfout of een app die blijft laden.

Op Wi-Fi zitten je telefoon en private cloud in hetzelfde LAN. De verbinding kan een lokaal adres gebruiken zoals 192.168.1.50, een lokale hostnaam of automatische ontdekking. Op mobiele data zit je telefoon op het netwerk van de provider. Het moet je thuisserver via een extern pad bereiken, niet via hetzelfde lokale pad.

Succes op Wi-Fi bewijst alleen dat het lokale pad werkt. Falen op mobiele data betekent dat het externe pad ontbreekt, geblokkeerd is, verkeerd is geconfigureerd of niet compatibel is met het mobiele netwerk. Problemen oplossen moet interne toegang scheiden van externe toegang in plaats van ze als één verbinding te behandelen.

De app kan een lokaal adres gebruiken dat alleen thuis werkt

De meest voorkomende oorzaak is ook de eenvoudigste. De private cloud-app kan zijn opgeslagen met een URL zoals http://192.168.1.50:8080, https://cloud.local, https://nas.local, of een door de router toegewezen apparaatsnaam. Die adressen werken thuis, maar falen overal elders.

Privé IPv4-bereiken zoals 10.x.x.x, 172.16–31.x.x en 192.168.x.x zijn bedoeld voor privé-netwerken. Een alleen lokaal privé-adres is geen openbaar internetadres, dus je telefoon kan dit niet rechtstreeks bereiken via mobiele data.

Als de mobiele app een alleen-LAN-URL gebruikt, begin dan niet met het willekeurig wijzigen van firewallinstellingen. Bepaal eerst of mobiele toegang via een openbaar domein, een VPN of mesh VPN, of een tunnel moet verlopen. Zonder een van deze paden probeert de telefoon een adres te bereiken dat alleen binnen je huis bestaat.

Interne URL en externe URL worden vaak door elkaar gehaald

Veel privé cloud-omgevingen eindigen met twee identiteiten. De interne URL werkt thuis, zoals http://192.168.1.50:8080. De externe URL moet werken vanaf buiten, zoals https://cloud.example.com of een tunnel-hostnaam.

Die twee namen kunnen naar dezelfde dienst wijzen, maar ze zijn niet hetzelfde toegangstype. De interne URL kan een privé-IP, lokale DNS of een zelfondertekend certificaat gebruiken. De externe URL kan publieke DNS, HTTPS, een reverse proxy, poortdoorsturing, VPN-routing of een tunnel vereisen.

Problemen ontstaan wanneer bladwijzers, mobiele apps, synchronisatieclients en browser-snelkoppelingen deze identiteiten door elkaar gebruiken. Gebruik voor mobiele data de externe URL als de dienst bedoeld is om van buitenaf bereikbaar te zijn. Wil je alles privé houden, maak dan eerst verbinding via VPN en gebruik daarna het LAN-adres.

DNS kan correct oplossen via Wi-Fi maar falen via mobiel netwerk

Een domein kan thuis werken en falen op mobiele data omdat de telefoon een ander DNS-systeem raadpleegt. Thuis kan je router, Pi-hole, AdGuard Home of lokale DNS-server cloud.example.com naar een intern IP-adres. Bij mobiele data kan de DNS van de provider of publieke DNS een ander antwoord geven of helemaal geen antwoord.

Dit komt vaak voor bij split DNS-configuraties. Binnen het LAN wijst het domein naar het privé-adres voor snelheid en eenvoud. Buiten het LAN moet het wijzen naar een openbaar IP, een via VPN toegankelijke naam of een tunnelendpoint. Als het externe record ontbreekt of verouderd is, kan de telefoon de dienst niet vinden.

Ga er niet van uit dat een domein correct is alleen omdat het werkt via Wi-Fi. Test hetzelfde domein op mobiele data en bevestig waar het wordt opgelost. Als interne en externe DNS-resultaten bewust verschillen, documenteer dat ontwerp zodat app-instellingen niet per ongeluk de verkeerde naam gebruiken.

Vertrouwde domeinen, basis-URL's en reverse proxies kunnen mobiele toegang weigeren

Soms bereikt het mobiele verzoek de server, maar faalt de app nog steeds. Je kunt een waarschuwing voor een onbetrouwbaar domein, een foutmelding over een ongeldige host, inlogproblemen, een redirectlus of een WebDAV-synchronisatieprobleem zien. Dit betekent meestal dat het pad de privé cloud heeft bereikt, maar de applicatie vertrouwt de naam of proxyheaders die het ontving niet.

Privé cloudsoftware heeft vaak expliciete instellingen voor hostnaam en URL nodig. De configuratiereferentie van Nextcloud bevat vertrouwde domein- en basis-URL-instellingen, en de documentatie over reverse proxy behandelt reverse proxy URL-detectie wanneer automatische detectie van hostnaam, protocol of webroot faalt.

Als mobiel internet de inlogpagina laadt maar inloggen, omleidingen, synchronisatie of deel-links falen, controleer dan de app-configuratie. De externe hostnaam moet vertrouwd zijn, de publieke URL moet overeenkomen met wat gebruikers invoeren, proxy-headers moeten correct zijn en HTTP-naar-HTTPS-omleidingen mogen de app niet terugsturen naar een privé LAN-adres.

HTTPS-certificaten Onthullen Vaak het Verkeerde Toegangsontwerp

Wi-Fi-toegang kan werken met een zelfondertekend certificaat, een interne hostnaam of een browserwaarschuwing die je maanden geleden handmatig hebt geaccepteerd. Mobiele apps kunnen strenger zijn, vooral bij het synchroniseren van bestanden, foto’s, agenda’s of WebDAV-gegevens op de achtergrond.

HTTPS-certificaten zijn gekoppeld aan namen. Als de app verbinding maakt met 192.168.1.50, cloud.local, of een andere hostnaam dan het certificaat, kunnen mobiele clients de verbinding weigeren. Als een reverse proxy de hostnaam of het protocol verkeerd aanpast, kan de app ook falen na inloggen.

Een schone externe setup gebruikt één stabiel publiek domein met een geldig certificaat en een bijpassende reverse proxy-configuratie. Een schone privésetup gebruikt eerst VPN of mesh VPN, daarna interne toegang. Het mengen van IP-adressen, lokale namen, publieke namen en niet-overeenkomende certificaten maakt mobiele toegang onbetrouwbaar.

Poortdoorsturing, VPN of Tunnel Moet het Mobiele Pad Bieden

Een privécloud wordt niet automatisch bereikbaar via mobiel internet alleen omdat het op Wi-Fi werkt. Verkeer van buitenaf heeft een bewuste route nodig naar het thuisnetwerk of het service-eindpunt.

Er zijn drie veelvoorkomende patronen. Poortdoorsturing stuurt specifiek publiek verkeer via de router naar de privécloud. Een VPN of mesh VPN laat de telefoon eerst lid worden van een privénetwerk. Een reverse tunnel laat de server een uitgaande verbinding maken naar een openbaar eindpunt, waarna mobiele apparaten via dat eindpunt verbinden.

Voor persoonlijke privécloudtoegang is VPN of mesh VPN meestal de veiligere eerste keuze. Voor het direct delen van een dienst met anderen kan een publieke domeinnaam met HTTPS, reverse proxy en zorgvuldige toegangscontrole geschikt zijn. Voor CGNAT of streng afgeschermde routers kan een tunnel praktischer zijn dan poortdoorsturing.

CGNAT kan port forwarding correct laten lijken maar toch laten falen

CGNAT is frustrerend omdat de thuisopstelling correct kan lijken. De private cloud werkt op Wi-Fi. De serverfirewall staat de poort toe. De router heeft een forwarding-regel. Maar mobiele data kan de dienst nog steeds niet bereiken.

Het probleem is dat je router mogelijk geen echt publiek IPv4-adres heeft. RFC 6598 reserveert 100.64.0.0/10 als gedeelde adresruimte gebruikt voor CGNAT. Wanneer je ISP je router achter carrier-grade NAT plaatst, kan verkeer van buitenaf je thuisrouter nooit bereiken, dus heeft je port forwarding-regel niets om door te sturen.

Vergelijk het WAN-IP dat op je router wordt weergegeven met het publieke IP dat een externe IP-checksite toont. Als ze niet overeenkomen, of als het WAN-adres binnen gedeelde of private reeksen valt, is klassieke port forwarding waarschijnlijk niet de juiste oplossing. Gebruik in plaats daarvan een publieke IP-optie van de ISP, een mesh VPN of een reverse tunnel.

Mobiele netwerken kunnen IPv6- en provider-specifieke problemen toevoegen

Sommige problemen doen zich alleen voor op mobiele data. Dezelfde private cloud kan werken vanaf een ander Wi-Fi-netwerk, maar falen op 5G of LTE. Of de ene provider werkt terwijl de andere dat niet doet. Dat wijst voorbij de thuisrouter.

Mobiele netwerken kunnen IPv6-only ontwerpen, NAT64, CGNAT, provider-DNS, APN-beleid, filtering of proxygedrag gebruiken. De richtlijnen van Apple over compatibiliteit met IPv6-only mobiele netwerken herinneren eraan dat mobiele netwerken zich mogelijk niet gedragen als een normaal dual-stack thuisnetwerk, vooral als een app of server uitgaat van IPv4-only gedrag.

Als mobiele data de enige foutieve verbinding is, test dan vanuit meerdere invalshoeken. Probeer dezelfde URL in een mobiele browser, test een andere provider of hotspot, controleer A- en AAAA-DNS-records, bevestig of de server het gebruikte adresfamilie ondersteunt, en probeer VPN via mobiele data. Als VPN werkt, is de private cloud waarschijnlijk in orde; het publieke mobiele pad is het probleem.

Mobiele apps kunnen zich anders gedragen dan browsers

Een telefoonbrowser en een mobiele app gedragen zich niet altijd hetzelfde. De browser kan de inlogpagina openen, terwijl de app niet kan synchroniseren. Of de app werkt op Wi-Fi omdat hij de server lokaal ontdekt, maar faalt op mobiele data omdat die ontdekking niet meer beschikbaar is.

Mobiele apps kunnen een oude server-URL cachen, HTTPS vereisen, certificaatafwijkingen weigeren, een WebDAV- of API-eindpunt gebruiken dat anders is dan de browserpagina, achtergrondgegevens beperken of omleidingen anders volgen. Sommige apps slaan ook aparte interne en externe serveradressen op zonder dat duidelijk te maken.

Test altijd beide paden. Open de externe URL in de telefoonbrowser terwijl u mobiele data gebruikt en test vervolgens de app. Als de browser ook faalt, ligt het probleem waarschijnlijk bij DNS, routing, TLS, CGNAT of tunnelconfiguratie. Als de browser werkt maar de app faalt, richt u zich op app-URL-instellingen, vertrouwde domeinen, certificaten, WebDAV/API-paden en app-cache.

VPN of Mesh VPN lost het probleem vaak op door het LAN-pad te herstellen

Als de private cloud werkt via Wi-Fi maar niet via mobiele data, kan een VPN een nette oplossing zijn omdat het de positie van de telefoon verandert. In plaats van de private cloud te bereiken als een willekeurige externe client, sluit de telefoon zich eerst aan bij een privé-netwerk.

Mesh VPN-tools kunnen directe of relay-paden gebruiken, afhankelijk van de betrokken netwerken. Tailscale documenteert privétoegang via directe of gerelayde verbindingen, wat nuttige context biedt wanneer een mobiel apparaat een thuisserver moet bereiken zonder de private cloud direct aan het internet bloot te stellen.

Voor persoonlijk gebruik is dit meestal het minst verwarrende model. De app kan het interne LAN-adres of een privé-DNS-naam gebruiken nadat de VPN is verbonden. De private cloud blijft buiten het open internet en het mobiele apparaat verifieert zich voordat het interne diensten bereikt.

Reverse tunnels helpen wanneer u een externe URL nodig hebt zonder poorten te openen

Een reverse tunnel is handig wanneer u geen inkomende poorten op uw router kunt of wilt openen. Dit komt vaak voor bij CGNAT, vergrendelde ISP-routers, internet in appartementen of gebruikers die de thuisrouter niet direct willen blootstellen.

Cloudflare Tunnel gebruikt een uitgaande tunnel voor externe toegang, waarbij de connector binnen uw netwerk de verbinding naar buiten initieert. Mobiele apparaten krijgen vervolgens toegang tot een openbare hostnaam die via de tunnel terugleidt.

Dit kan het mobiele datatoegang vergemakkelijken, maar het moet nog steeds zorgvuldig worden geconfigureerd. Gebruik toegangsbeleid, HTTPS, beperkte service-exposure en scheid beheerdersinterfaces van openbare gebruikersdiensten. Een tunnel lost bereikbaarheid op; het lost niet automatisch permissies of app-configuratie op.

Een praktische volgorde voor probleemoplossing

Dit probleem wordt ingewikkeld als DNS, routerregels, certificaten, app-instellingen en mobiele netwerken allemaal tegelijk veranderen. Een betere aanpak is om één laag tegelijk te testen.

Begin met het opschrijven van de exacte URL die werkt op wifi. Bepaal of het een privé-IP, lokale hostnaam of openbaar domein is. Zet dan wifi uit en test dezelfde URL via mobiele data. Test vervolgens het bedoelde openbare domein, controleer publieke DNS, vergelijk router WAN IP met openbaar IP, bevestig of je port forwarding, VPN of tunnel gebruikt, en controleer daarna het TLS-certificaat en de vertrouwde domeininstellingen.

Het resultaat wijst meestal naar de laag. Als browser en app allebei falen, richt je op DNS, publieke route, CGNAT, certificaat of tunnel. Als browser werkt maar app faalt, richt je op app-configuratie, vertrouwde domeinen, WebDAV/API-eindpunten, redirects en gecachte server-URL’s. Als VPN via mobiele data werkt, is de private cloud gezond; het externe pad is het probleem.

De veiligere standaard is één duidelijk patroon voor externe toegang

Private cloud-toegang wordt onbetrouwbaar als er te veel halfwerkende ingangen zijn: een LAN IP, een lokale hostnaam, een DDNS-naam, een tunnel-URL, een oude app-URL, een reverse proxy-hostnaam en een bladwijzer die niemand zich herinnert te hebben aangemaakt.

Kies één hoofdpatroon. Voor persoonlijke toegang is lokaal plus VPN vaak de schoonste oplossing. Voor directe app-toegang van buitenaf, gebruik één openbaar domein, geldig HTTPS, correcte vertrouwde domeininstellingen en een veilige reverse proxy of tunnel. Bij CGNAT gebruik je beter een tunnel of mesh VPN in plaats van te vechten met port forwarding.

Hoe minder toegangspunten je onderhoudt, hoe eenvoudiger de telefooninstelling wordt. Een private cloud zou niet voor elk netwerk een andere mysterieuze URL moeten nodig hebben. Stabiele naamgeving, bijpassende certificaten en een duidelijke toegangsweg zorgen ervoor dat wifi en mobiele data consistent werken.

Belangrijkste conclusie

Als je private cloud werkt op Wi-Fi maar niet op mobiel internet, is de private cloud zelf waarschijnlijk in orde. Wi-Fi gebruikt een lokaal pad. Mobiel internet heeft een extern pad nodig. De fout wordt meestal veroorzaakt door een lokaal-only URL, DNS-mismatch, ontbrekende port forwarding, VPN of tunnel, CGNAT, TLS-certificaat mismatch, vertrouwde domeinconfiguratie, IPv6/IPv4-gedrag of verschillen in de mobiele app.

Begin met controleren welke URL de app gebruikt, of die URL lokaal of publiek is, of publieke DNS wordt opgelost, of de router een echt publiek IP heeft en of HTTPS en vertrouwde domeinen overeenkomen met de externe naam. Voor persoonlijk gebruik is VPN of mesh VPN meestal de beste oplossing. Voor directe externe toegang gebruik je een consistent publiek domein, geldig certificaat en een zorgvuldig beveiligd pad.

Een betrouwbare private cloud NAS kan bestanden, foto’s, synchronisatie, back-ups en externe toegang hosten, maar toegang via mobiel internet hangt nog steeds af van het netwerkpad, domein, certificaat en de app-configuratie daaromheen.

FAQ

Waarom werkt mijn private cloud op Wi-Fi maar niet op mobiel internet?

Wi-Fi gebruikt je lokale netwerk, waar privé-IP-adressen en lokale hostnamen kunnen werken. Mobiel internet gebruikt het netwerk van de provider, dus het heeft een publiek domein, VPN, tunnel of een ander extern toegangspad nodig.

Kan ik 192.168.x.x gebruiken op mobiel internet?

Nee. Een 192.168.x.x adres is privé en werkt alleen binnen je lokale netwerk. Om het via mobiel internet te gebruiken, maak eerst verbinding met je thuisnetwerk via VPN of mesh VPN.

Waarom werkt mijn domein thuis wel maar niet op mobiel internet?

Je thuis-Wi-Fi kan lokale DNS gebruiken die het domein naar een privé-IP verwijst. Op mobiel gebruikt de telefoon publieke of provider-DNS, die mogelijk niet hetzelfde record heeft of naar het verkeerde eindpunt verwijst.

Waarom werkt de browser wel maar de mobiele app niet?

De app kan een andere API- of WebDAV-route gebruiken, een oude URL cachen, een vertrouwd domein vereisen, een certificaat weigeren of omleidingen anders afhandelen dan de browser.

Beïnvloedt CGNAT de toegang tot de private cloud via mobiel internet?

Ja. Als je thuis-ISP CGNAT gebruikt, kan port forwarding je router nooit bereiken. Gebruik in dat geval een publieke IP-optie, VPN/mesh VPN of een reverse tunnel.

Kan IPv6 problemen veroorzaken bij toegang via mobiel internet?

Dat kan. Sommige mobiele netwerken gebruiken alleen IPv6 of geven de voorkeur aan IPv6. Als je domein, app of thuisserver alleen IPv4 ondersteunt of onjuiste DNS-records heeft, kan mobiel internet zich anders gedragen dan Wi-Fi.

Is VPN beter dan poorten openen voor een private cloud?

Voor persoonlijk gebruik meestal wel. VPN of mesh VPN houdt de private cloud buiten het open internet en laat vertrouwde apparaten er toegang toe krijgen alsof ze op het thuisnetwerk zitten.

Wat moet ik als eerste controleren?

Controleer de URL die in de app is opgeslagen. Als het een lokaal IP-adres is of .local hostname, het werkt niet op mobiel internet tenzij je een VPN gebruikt. Controleer dan de publieke DNS, CGNAT, HTTPS, vertrouwde domeinen en app-instellingen.