Pourquoi Android coupe mon VPN avec NetGuard, un bloqueur DNS ou Super Proxy : ils se disputent la même place

Je n’ai compris que mon VPN avait disparu qu’en regardant mon adresse IP.

Quelques minutes plus tôt, tout paraissait pourtant mieux protégé qu’avant.

Mon VPN habituel était connecté. J’avais ensuite lancé NetGuard parce que je voulais empêcher deux applications de communiquer en arrière-plan. Android avait demandé l’autorisation habituelle. J’avais accepté.

NetGuard fonctionnait. Internet aussi. Et l’icône VPN était toujours affichée en haut de l’écran. J’aurais pu m’arrêter là.

Puis j’ai ouvert une page de vérification d’IP. Au lieu de la sortie VPN que j’utilisais juste avant, je retrouvais l’adresse de ma connexion normale.

J’ai relancé mon VPN. NetGuard s’est arrêté. J’ai réactivé NetGuard. Le VPN est retombé. À ce moment-là, je pensais encore avoir trouvé un bug entre deux applications. En réalité, Android faisait exactement ce pour quoi il avait été conçu.

Ce n’était pas un conflit entre deux marques

La confusion est d’autant plus facile aujourd’hui qu’Android ajoute lui-même de nouvelles protections réseau. Le 27 août 2026, Google a notamment présenté pour Android 17 des améliorations autour du DNS privé et d’Encrypted Client Hello, destinées à limiter certaines informations visibles sur les destinations consultées.

Dans ce contexte, ajouter un pare-feu, un bloqueur DNS ou un proxy à son VPN paraît presque évident : une protection pour chaque problème.

C’est précisément là que je me trompais.

Android fournit aux applications une API appelée VpnService. Elle permet à une application de créer une interface réseau virtuelle et d’y faire passer le trafic du téléphone.

Le détail important tient en une phrase : Android ne garde qu’un seul service VPN actif par utilisateur ou profil. Lorsqu’une autre application prend cette place, le service précédent est arrêté.

J’avais imaginé une pile : VPN → NetGuard → Internet. Android faisait quelque chose de beaucoup plus simple : NetGuard à la place du VPN. L’icône en haut de l’écran pouvait donc rester visible. Un service VPN était toujours actif. Ce n’était simplement plus celui que je pensais.

NetGuard m’a fait comprendre pourquoi le mot « VPN » est trompeur ici

NetGuard n’est pas un VPN commercial caché sous un autre nom.

Sur un téléphone Android non rooté, il utilise néanmoins le service VPN local du système pour intercepter les connexions et appliquer ses règles de pare-feu. Sa propre FAQ l’explique clairement : comme Android n’autorise qu’une application à utiliser ce mécanisme à la fois, NetGuard ne peut pas fonctionner simultanément avec une autre application qui dépend elle aussi de VpnService.

C’est là que mon premier raisonnement s’est effondré. Je pensais choisir entre : « VPN activé » et « VPN désactivé ». La vraie question était : quelle application possède actuellement l’unique emplacement VPN qu’Android met à ma disposition ?

À partir de là, le comportement cessait déjà de ressembler à une panne mystérieuse.

Mais je voulais vérifier si le problème venait vraiment de cette architecture ou seulement de NetGuard.

Mon deuxième essai semblait pourtant complètement différent

J’ai remplacé NetGuard par un bloqueur DNS.

Mon besoin était devenu plus simple : je ne voulais plus contrôler chaque application. Je voulais surtout éliminer une partie des publicités, domaines de suivi et requêtes inutiles.

Un bloqueur DNS me paraissait beaucoup moins susceptible d’entrer en conflit avec un VPN.

Et parfois, c’est effectivement le cas.

Android possède son propre réglage DNS privé. Google précise que cette fonction protège les requêtes et réponses DNS ; elle ne vient pas occuper, à elle seule, l’emplacement d’un deuxième client VPN.

Le problème commence lorsque l’application de blocage utilise elle aussi un VPN local pour filtrer tout le trafic du téléphone.

AdGuard, par exemple, documente ce fonctionnement avec son mode « Local VPN » : l’application crée une interface VPN locale pour effectuer le filtrage et ne peut alors pas fonctionner normalement en parallèle avec un autre VPN Android utilisant le même mécanisme.

La distinction m’a enfin paru plus utile que le nom écrit sur l’icône.

Un outil peut s’appeler « bloqueur », « pare-feu » ou « DNS ».

S’il demande à Android de créer une connexion VPN locale, il arrive devant la même porte que mon VPN principal.

Et il demande la même clé.

Super Proxy m’a retiré mon dernier doute

Je pensais encore avoir trouvé une échappatoire avec Super Proxy.

Après tout, un proxy n’est pas un VPN.

J’avais un serveur SOCKS5 disponible et je voulais simplement faire passer certaines applications par celui-ci. Cela ressemblait à une autre couche réseau, donc à quelque chose qui pouvait cohabiter avec mon tunnel.

J’ai activé le profil. Même scénario. Mon VPN précédent n’était plus celui qui transportait le téléphone.

Cette fois, l’explication se trouvait directement dans le fonctionnement de Super Proxy : l’application utilise un service VPN local Android pour faire transiter les applications par un proxy HTTP ou SOCKS5 sans nécessiter de root.

Trois outils. Trois usages différents. Mais la même demande adressée à Android : laisse-moi contrôler le trafic grâce àVpnService. Android ne leur construit pas trois étages. Il choisit un occupant.

Pourquoi cela ressemble si facilement à une nouvelle panne Android

Le symptôme est suffisamment déroutant pour qu’on l’attribue facilement à une mise à jour.

En juillet 2026, un utilisateur Android racontait publiquement qu’AdGuard avait commencé à désactiver Mullvad lorsqu’il essayait d’utiliser les deux ensemble. Comme il avait l’impression que cette combinaison avait auparavant mieux fonctionné, il soupçonnait d’abord un changement récent.

La discussion revenait pourtant à la même limite fondamentale : lorsqu’un bloqueur utilise un VPN local, activer un autre client VPN revient à faire reprendre cette place par une seconde application.

Je comprends facilement pourquoi on se trompe. Deux applications peuvent rester ouvertes. Le bloqueur peut encore afficher son interface. Une notification peut rester visible. Et l’icône de clé d’Android ne dit pas forcément quel service transporte actuellement les données.

J’ai donc arrêté d’interpréter l’icône et adopté un test beaucoup plus simple :

je connecte mon VPN, je vérifie l’adresse IP de sortie, j’active l’autre outil, puis je vérifie de nouveau.

En quelques secondes, je sais qui a réellement pris la route.

J’ai surtout arrêté d’essayer d’empiler deux protections

À ce stade, mon besoin était devenu évident. Je n’avais pas réellement besoin de maintenir en permanence les règles détaillées de NetGuard. Je n’avais pas non plus besoin de mon proxy SOCKS5 à chaque connexion. Au quotidien, je voulais surtout deux choses : garder mon tunnel VPN actif ;

et supprimer une partie des requêtes publicitaires et de suivi.

Jusque-là, j’essayais de résoudre ces deux besoins avec deux applications qui se disputaient la même interface Android.

C’est à ce moment-là que j’ai lancé OnlydogVPN. Je n’ai installé aucun deuxième bloqueur. J’ai connecté le tunnel, puis vérifié l’adresse IP de sortie. Elle correspondait bien à celle du VPN.

Ensuite, j’ai activé le mode de blocage intégré dans la même application et rechargé les pages utilisées pour le test.

Elles ont continué à fonctionner. J’ai vérifié une nouvelle fois l’IP. Elle n’était pas revenue à celle de mon opérateur.

C’était exactement le résultat que je cherchais depuis le début : le filtrage fonctionnait sans qu’une deuxième application vienne reprendre à son compte l’unique emplacement VPN d’Android.

Tout à coup, le problème qui m’avait fait alterner entre NetGuard, le bloqueur DNS et Super Proxy n’existait plus.

Je n’avais pas trouvé une astuce pour forcer Android à accepter deux VPN.

Je n’en avais simplement plus besoin.

Le compteur m’a permis de vérifier que je n’avais pas seulement supprimé le conflit

Une fois le tunnel stabilisé, j’ai continué à utiliser le téléphone normalement.

C’est là que le compteur de requêtes bloquées m’a paru utile.

Avec mes essais précédents, savoir que le filtrage fonctionnait était presque indissociable du problème : l’autre VPN cessait d’être le tunnel actif.

Cette fois, je pouvais constater les deux choses séparément.

La sortie VPN restait en place.

Et le compteur continuait à montrer des requêtes publicitaires ou de suivi bloquées pendant ma navigation.

Ce détail m’a donné une raison supplémentaire de conserver l’application, parce qu’il transformait quelque chose d’assez invisible en résultat vérifiable.

Cela ne veut pas dire que NetGuard ou Super Proxy deviennent inutiles.

Si je voulais empêcher très précisément une application particulière d’accéder au réseau, les règles de NetGuard resteraient plus adaptées.

Si je devais impérativement utiliser un proxy SOCKS5 fourni par mon entreprise, je garderais un outil conçu pour ce besoin.

Le petit service possède aussi moins de régions et moins d’historique public que plusieurs fournisseurs VPN installés depuis longtemps.

Mais aucune de ces différences ne répondait au problème qui m’avait amené ici.

Je cherchais un VPN que je puisse laisser actif tout en bénéficiant du filtrage dont j’avais réellement besoin.

Et, dans mon test, c’est précisément ce que cette approche m’a permis de faire.

Le réglage qui compte est finalement celui que je n’ai plus besoin d’activer

Avant ce test, mon téléphone ressemblait à une accumulation de bonnes intentions. Un VPN pour le tunnel. Un pare-feu pour les applications. Un bloqueur pour le DNS. Un proxy pour certains usages. Pris séparément, chacun pouvait avoir une raison d’exister.

Ensemble, sur un Android non rooté, plusieurs demandaient simplement la même chaise.

Et une seule application pouvait s’y asseoir.

Depuis, lorsque l’activation de NetGuard, d’un bloqueur ou d’un proxy coupe immédiatement mon VPN, je ne commence plus par changer de serveur, réinstaller le client ou accuser la batterie.

Je regarde d’abord si la nouvelle application utilise VpnService.

Si oui, la déconnexion n’est généralement pas mystérieuse : Android vient de remplacer l’application qui occupait son interface VPN.

Et pour mon besoin précis — garder le VPN actif tout en bloquant une partie du suivi — réunir ces deux fonctions dans le même tunnel s’est révélé beaucoup plus utile que continuer à faire alterner deux applications sur l’unique place qu’Android leur accorde.