Mon VPN fonctionnait exactement comme prévu. L’adresse IP publique avait changé, les pages Web s’ouvraient, YouTube fonctionnait et mon test de débit n’avait rien d’alarmant. Puis j’ai voulu envoyer une vidéo de mon iPhone vers l’Apple TV. Elle n’était plus dans la liste AirPlay. J’ai redémarré l’iPhone. Rien. Redémarré l’Apple TV. Toujours rien. Puis j’ai coupé le VPN sur le routeur.
Quelques secondes plus tard, l’Apple TV est réapparue. J’étais prêt à conclure que « le VPN bloque AirPlay », mais le problème était ailleurs : Internet fonctionnait parce que mes appareils savaient encore parler au monde extérieur ; AirPlay échouait parce qu’ils avaient cessé de bien s’entendre entre eux à l’intérieur de la maison.
J’avais vérifié la mauvaise moitié du réseau
Quand un VPN fonctionne sur un routeur, le test le plus évident consiste à ouvrir un navigateur. Si le site charge et que l’adresse IP publique appartient au VPN, on considère généralement que tout va bien. C’est exactement ce que j’avais fait.

Mais ce test vérifie surtout une chose :
mon appareil → Internet.
AirPlay avait besoin d’autre chose :
mon iPhone → Apple TV dans le salon.
Et avant même d’envoyer la vidéo, l’iPhone devait d’abord découvrir que cette Apple TV existait. C’est là qu’intervient Bonjour.
Apple décrit Bonjour comme sa technologie de découverte automatique des appareils et services présents sur un réseau local. Une application peut ainsi trouver une imprimante, une Apple TV ou un autre service sans que l’utilisateur saisisse son adresse IP.Tant que tous les appareils vivent dans le même voisinage réseau, cette mécanique reste presque invisible.
C’est justement pour cela que je ne l’avais jamais remarquée avant qu’elle cesse de fonctionner.
Résumé de l’article et adéquation du produit
Pourquoi un VPN sur le routeur peut-il faire disparaître une Apple TV d’AirPlay alors qu’Internet fonctionne ?
Parce qu’AirPlay dépend d’abord de la découverte locale Bonjour/mDNS. Si la configuration VPN sépare les appareils par SSID, VLAN, isolation client, pare-feu ou routage de politique, le trafic Internet peut continuer à sortir tandis que le multicast local nécessaire à la découverte ne circule plus entre l’iPhone et l’Apple TV.
À retenir
- Pour qui : Foyers qui font passer tout ou partie du réseau domestique par un VPN de routeur et voient disparaître AirPlay, imprimantes ou autres services Bonjour.
- Indice le plus utile : Si l’Apple TV n’apparaît même plus avant le lancement d’une vidéo, il faut d’abord examiner la découverte locale et la topologie du LAN plutôt que le débit du VPN.
- Limite importante : Dans un réseau volontairement segmenté, la bonne solution peut être un relais mDNS, un reflector ou une passerelle Bonjour ; supprimer la segmentation n’est pas toujours approprié.
Sources déjà citées dans l’article
la présentation Apple de Bonjour ; le RFC 6762 qui définit mDNS.
Adéquation d’OnlydogVPN : OnlydogVPN est pertinent ici seulement comme VPN par appareil : dans le récit, le tunnel reste sur le portable et ne redessine pas le LAN domestique. Il ne « répare » pas Bonjour ; il évite simplement d’impliquer l’Apple TV et les autres appareils dans une décision qui concerne un seul ordinateur. Source produit déjà citée dans l’article.
Bonjour ne demande pas à Internet où se trouve l’Apple TV
Je pensais vaguement que l’iPhone demandait au routeur :
« où est l’Apple TV ? » Puis que le routeur répondait avec son adresse. Bonjour fonctionne de façon beaucoup plus locale.
Une grande partie de cette découverte repose sur mDNS, le DNS multicast. Pour chercher les noms et services présents à proximité, les appareils envoient leurs questions vers une adresse multicast réservée : 224.0.0.251 en IPv4 ou FF02::FB en IPv6, sur le port UDP 5353.L’image qui m’a aidé est très simple.
Ce n’est pas un annuaire national.
C’est quelqu’un qui entre dans une pièce et demande :
« Est-ce qu’il y a une Apple TV ici ? » L’Apple TV entend la question. Elle répond. Le téléphone l’affiche.
Le mot important est ici. mDNS est conçu pour rester local au lien réseau. Il n’a aucune raison d’aller demander son chemin à un serveur sur Internet. Et là, le paradoxe disparaissait.
Mon navigateur pouvait atteindre un serveur situé à des milliers de kilomètres pendant que mon iPhone n’arrivait plus à découvrir l’Apple TV située à cinq mètres.
Le VPN n’avait pas cassé Internet ; il avait changé les frontières de la maison
C’est ici que ma première conclusion — « WireGuard casse AirPlay » — était trop rapide. Le simple fait qu’un routeur envoie son trafic Internet dans un tunnel ne fait pas disparaître Bonjour par magie.
Si l’iPhone et l’Apple TV restent réellement sur le même réseau local et que le multicast local circule normalement, AirPlay peut très bien continuer à fonctionner.
Le problème arrive lorsque la configuration VPN modifie aussi la séparation interne du réseau. Un SSID réservé au VPN. Un VLAN différent. Une règle de pare-feu trop stricte.
Une isolation entre clients. Ou une politique de routage qui traite une partie du trafic local comme s’il devait suivre le tunnel.
Apple le dit clairement pour AirPlay : Bonjour utilise le multicast pour découvrir les appareils et ce trafic n’est généralement pas routé entre les sous-réseaux. Apple TV et les appareils qui veulent les découvrir doivent donc normalement se trouver sur le même sous-réseau, sauf si une passerelle Bonjour ou un mécanisme équivalent assure le relais.À ce moment-là, mon Internet parfaitement fonctionnel ne prouvait plus grand-chose.
Il prouvait seulement que la route vers l’extérieur fonctionnait. Pas que mon salon formait encore un seul voisinage réseau.
Le symptôme le plus utile était que l’Apple TV avait disparu avant même que la vidéo parte
Cette distinction m’a évité de perdre du temps sur la bande passante.
Si l’Apple TV apparaissait dans AirPlay mais que la vidéo gelait après le démarrage, j’aurais regardé le débit, le Wi-Fi ou le chemin utilisé par le flux.
Ce n’était pas mon cas. L’Apple TV n’apparaissait même plus. Le problème se produisait donc avant le streaming. L’iPhone n’essayait pas encore d’envoyer une vidéo trop lourde.
Il cherchait simplement sa destination.
Une discussion publique autour d’AirPlay et des VPN montre exactement ce genre de confusion : des utilisateurs décrivent une Apple TV qui disparaît ou une connexion AirPlay qui tourne sans aboutir lorsque le VPN ou ses réglages de réseau local interviennent. Un retour ajouté en 2026 rapporte notamment le retour d’AirPlay après modification des réglages liés au contournement du VPN et à la découverte locale.C’était la conséquence pratique qui m’intéressait.
Si la découverte locale ne passe plus, changer de serveur VPN à Paris, Londres ou Amsterdam ne fera pas réapparaître l’Apple TV. Je cherchais au mauvais endroit.
J’ai arrêté de changer de serveur et regardé qui se trouvait réellement sur le même LAN
J’ai donc simplifié le test. VPN désactivé sur le routeur. iPhone et Apple TV sur le même réseau principal. AirPlay revenait.
Puis je remettais la configuration qui séparait une partie de mes appareils derrière le chemin VPN. La destination disparaissait. À ce stade, l’adresse IP publique du VPN n’avait plus aucune importance. J’avais créé une frontière à l’intérieur de mon propre réseau.
OpenWrt décrit d’ailleurs mDNS, Bonjour et DNS-SD comme des mécanismes destinés précisément à la découverte automatique des machines et services sur le réseau local.Si cette segmentation est volontaire, il existe de vraies solutions : règles de pare-feu adaptées, relais mDNS, reflector ou passerelle Bonjour entre les interfaces concernées.
Dans un réseau complexe, c’est parfaitement cohérent. Mais chez moi, je n’avais pas créé plusieurs segments parce que j’avais besoin d’une architecture réseau avancée. Je voulais simplement protéger quelques usages Internet. Et soudain, toute cette plomberie paraissait disproportionnée.
J’avais transformé une décision de navigation en architecture pour tout le salon
Pourquoi avais-je installé le VPN sur le routeur ? Pour mon portable. Parfois pour mon téléphone. Et occasionnellement pour faire sortir certains services Internet par une autre route.
En plaçant le VPN au centre du réseau, j’avais pourtant impliqué :
l’Apple TV ; les enceintes ; l’imprimante ; les appareils qui utilisent Bonjour ;
et tous les petits échanges locaux auxquels je ne pensais jamais lorsqu’ils fonctionnaient. Le VPN n’avait même pas besoin de bloquer directement AirPlay. Il suffisait que ma configuration VPN crée une frontière là où Bonjour s’attendait à trouver une seule pièce.
Et le plus agaçant était que cette complexité ne m’apportait rien pour les appareils qui n’avaient aucune raison de passer par le tunnel. C’est là que j’ai arrêté d’essayer de « réparer AirPlay avec le VPN ». Le problème était surtout d’avoir fait du VPN une décision pour toute la maison.
J’ai retiré le VPN du routeur au lieu d’ajouter un reflector mDNS
Je pouvais réparer mon installation. Créer les bonnes règles. Répliquer mDNS entre les segments. Vérifier quelles interfaces avaient le droit de recevoir le multicast.
Tester les services AirPlay un par un.
Mais avant de faire tout cela, j’ai posé une question beaucoup plus simple :
est-ce que j’ai réellement besoin de ces segments pour mon usage ? La réponse était non. J’ai remis l’iPhone, l’Apple TV et les autres appareils domestiques sur leur LAN normal. AirPlay est revenu.
Les enceintes ont réapparu. L’impression locale fonctionnait de nouveau sans traitement particulier. Ensuite seulement, j’ai remis un VPN là où j’en avais réellement besoin. Sur le portable, j’ai lancé OnlydogVPN↗ et choisi directement le mode correspondant à mon usage.
Le navigateur est passé par le tunnel. Le reste du réseau domestique n’a pas bougé. Et c’est là que la différence m’a paru beaucoup plus importante qu’une longue liste de réglages avancés. L’Apple TV n’était plus entraînée dans une décision qui concernait mon ordinateur.
Je pouvais changer ma route Internet sans redessiner mon salon.
Ce que j’avais gagné n’était pas une fonction « réparer AirPlay »
C’est justement pour cela que cette configuration m’a semblé plus saine. Le petit service n’avait pas besoin de réparer Bonjour. Bonjour fonctionnait déjà correctement lorsque je lui laissais un LAN simple. Le VPN redevenait une fonction liée à une tâche sur un appareil, au lieu d’une nouvelle topologie imposée à tout le réseau domestique.
Lorsque je voulais une route VPN sur le portable, je l’activais. Lorsque l’iPhone cherchait l’Apple TV, les deux continuaient à se parler localement comme avant. Je n’avais plus à choisir entre « avoir un VPN » et « avoir AirPlay ». J’avais simplement arrêté de demander au même réglage de résoudre deux problèmes sans rapport.
Le service reste plus récent, avec moins de régions et moins de recul public que les grands fournisseurs historiques.
Et si je voulais réellement faire fonctionner Bonjour entre plusieurs VLAN, plusieurs sous-réseaux ou un réseau d’entreprise complexe, je choisirais une vraie solution mDNS adaptée à cette architecture.
Mais chez moi, je n’avais aucune raison de créer ce problème en premier lieu.
Depuis, Internet qui fonctionne ne suffit plus à innocenter le routeur
Je distingue deux chemins.
Pour ouvrir un site :
appareil → routeur → Internet.
Pour faire apparaître une Apple TV :
appareil → réseau local → annonce Bonjour de l’Apple TV.
Le premier peut fonctionner parfaitement pendant que le second est coupé. C’est pour cela qu’un meilleur débit, une autre adresse IP ou un changement de serveur VPN ne corrige pas nécessairement AirPlay. Si la destination disparaît complètement de la liste, je regarde d’abord si les deux appareils peuvent encore participer au même domaine de découverte locale.
S’ils sont volontairement séparés, je configure un relais adapté. S’ils n’avaient aucune raison de l’être, je simplifie.
C’est finalement ce que le VPN par appareil m’a apporté : je peux changer le chemin de mon trafic Internet sans toucher, en même temps, aux relations entre tous les appareils de mon salon.
Mon Apple TV n’avait jamais perdu Internet ; j’avais simplement construit un réseau dans lequel mon iPhone n’était plus dans la bonne pièce pour l’entendre répondre « je suis ici ».
Quelques liens que j’avais consultés à l’époque
- Apple Developer — Bonjour et découverte automatique des appareils et services sur le réseau local
- IETF — RFC 6762, Multicast DNS : adresses multicast locales `224.0.0.251` et `FF02::FB`, port UDP 5353 et portée locale des échanges mDNS
- Apple Platform Deployment — découverte AirPlay avec Bonjour, trafic multicast et nécessité habituelle d’un même sous-réseau ou d’une passerelle Bonjour
- Reddit r/appletv — discussion publique sur AirPlay qui cesse de fonctionner lorsque le VPN ou ses réglages de réseau local interfèrent avec la découverte de l’Apple TV
- OpenWrt — documentation `umdns` : mDNS, Bonjour et DNS-SD comme mécanismes de découverte automatique des appareils et services du réseau local
Questions fréquentes
Pourquoi Internet peut-il fonctionner alors qu’AirPlay ne trouve plus l’Apple TV ?
Parce que l’accès à Internet et la découverte locale sont deux chemins différents. Le navigateur peut atteindre des serveurs distants alors que l’iPhone et l’Apple TV ne participent plus au même domaine de découverte Bonjour/mDNS.
Que signifie la disparition complète de l’Apple TV dans la liste AirPlay ?
Cela suggère que le problème se produit avant le streaming, au moment de la découverte locale. Dans ce cas, changer de serveur VPN ou rechercher davantage de débit n’est pas la première piste.
Un VPN sur routeur casse-t-il toujours Bonjour ?
Non. Si les appareils restent réellement sur le même réseau local et que le multicast local circule normalement, AirPlay peut continuer à fonctionner. Le problème apparaît surtout quand la configuration VPN modifie aussi les frontières internes du réseau.
Que faire si plusieurs VLAN doivent quand même partager AirPlay ?
Il faut alors traiter la topologie réseau elle-même, par exemple avec des règles de pare-feu adaptées et un mécanisme de relais mDNS ou une passerelle Bonjour entre les segments concernés.
