Utilisez cette liste de contrôle pour examiner la diffusion sur un réseau scolaire ou professionnel géré. L’émetteur désigne l’ordinateur portable, le téléphone ou la
tablette ; le récepteur désigne le Chromecast ou l’écran compatible Cast. Vérifiez le modèle et le logiciel du récepteur : les implémentations intégrées aux écrans
peuvent avoir des exigences supplémentaires.
Visible ne signifie pas connecté. La découverte, le contrôle local et l’utilisation des contenus multimédias utilisent des flux différents. Un récepteur peut apparaître dans le menu Cast alors que la connexion réelle est bloquée.
1. Vérifications réseau requises
Adressage et isolation. Vérifiez que les deux appareils disposent d’une adresse IP, d’un masque de sous-réseau, d’une passerelle et d’une configuration DNS valides (DHCP ou paramètres statiques pris en charge). L’isolation des points d’accès/clients et les règles d’accès invité doivent autoriser la communication entre l’émetteur et le récepteur concernés. [1]
Découverte mDNS / Bonjour. Autorisez les requêtes et les réponses pour _googlecast._tcp.local. Entre les VLAN, configurez une passerelle, un répéteur ou un réflecteur mDNS pris en charge pour les réseaux et le service concernés. Ouvrir uniquement le port UDP 5353 ne permet pas de transporter la découverte locale entre les sous-réseaux. [2, 3]
Routage et trafic retour. Entre les VLAN, vérifiez les routes dans les deux sens. Autorisez le contrôle local et les contenus multimédias via les pare-feu réseau et de point de terminaison, y compris le trafic retour avec état. Privilégiez un chemin routé sans NAT entre les réseaux de diffusion. [4]
Autorisations de l’émetteur - requises lorsqu’elles sont demandées. Sur iOS/iPadOS 14+ et macOS 15+, activez Confidentialité et sécurité > Réseau local pour l’application de diffusion ou Chrome, puis rouvrez-la. [5]
2. Trafic à vérifier
Requis = nécessaire pour la fonction indiquée. Diagnostic = test temporaire, limité aux appareils de test. Les règles locales s’appliquent au sein du réseau ; les règles sortantes s’appliquent aux services Internet ou d’infrastructure.
| Trafic / ports | Chemin | Exigence / objectif |
|---|---|---|
|
mDNS UDP 5353 |
Découverte locale |
Requis pour la découverte standard. Multidiffusion IPv4 224.0.0.251 ; IPv6 ff02::fb lorsqu’il est utilisé. Vérifiez la transmission sans fil et filaire. [2, 3] |
|
Contrôle local TCP 8008-8009 |
De l’émetteur au récepteur |
Requis pour le contrôle Cast standard. Autorisez les réponses sur les connexions établies. Confirmez les ports spécifiques au modèle. [4] |
|
Contenus multimédias / mise en miroir UDP, ports dynamiques |
Entre l’émetteur et le récepteur, dans les deux sens |
Requis : le trafic multimédia doit passer. Diagnostic : autorisez temporairement UDP 1-65535 entre les appareils de test ; voir la portée ci-dessous. [4] |
|
HTTP / HTTPS TCP 80 / 443 |
De l’émetteur / du récepteur vers les services requis |
Requis lorsqu’il est utilisé pour la configuration, les mises à jour et les contenus en ligne. Vérifiez les domaines des services et les éventuels ports d’application supplémentaires. |
|
DNS UDP et TCP 53 |
Des appareils vers des résolveurs DNS opérationnels |
Requis : résolution de noms réussie. Examinez les requêtes bloquées ; vérifiez l’utilisation éventuelle de résolveurs externes propres à l’appareil. |
|
NTP UDP 123 |
Du récepteur vers son service de temps |
Requis lors de l’utilisation de NTP. Une heure correcte est nécessaire pour valider les certificats ; vérifiez l’heure et la synchronisation. |
Portée des ports : Google spécifie explicitement UDP 1-65535 pour Cast Moderator. Pour les autres récepteurs, confirmez les règles multimédias permanentes auprès du
fabricant. Ne supposez pas que TCP/UDP 32768-61000 est universel. Cast Moderator utilise également une méthode de découverte différente de Cast standard
basé sur mDNS. [4]
Identifier l’étape défaillante
Symptômes et vérifications pratiques
| Symptôme | Vérifications à effectuer |
|---|---|
| Le récepteur n’est pas visible | Confirmez que le récepteur est en ligne et que Cast est activé. Vérifiez l’isolation du point d’accès/client, les annonces de service mDNS, les règles de passerelle VLAN et l’autorisation Réseau local de l’émetteur. Essayez un autre émetteur ou une autre application compatible Cast. [1-3, 5] |
| Visible, mais impossible de se connecter | Vérifiez la route vers l’adresse IP annoncée du récepteur, TCP 8008-8009, les journaux du pare-feu/ACL et le trafic retour. Examinez les règles NAT et celles du VPN ou du pare-feu de point de terminaison de l’émetteur. La découverte seule ne vérifie pas ces chemins. [4] |
| La connexion fonctionne, mais la mise en miroir échoue | Vérifiez le filtrage des contenus multimédias UDP dans les deux sens. Appliquez le test de diagnostic UDP limité indiqué à la page 1. Sur l’émetteur, vérifiez l’autorisation d’enregistrement de l’écran lorsqu’elle est requise. Comparez avec un autre émetteur ou une autre application. |
| Les contenus en ligne échouent | Vérifiez l’accès Internet depuis le récepteur lui-même, les réponses DNS, TCP 80/443 et l’heure correcte/NTP. Examinez le filtrage des domaines, l’authentification du proxy et l’inspection SSL/TLS ; testez une exclusion ciblée. |
| Le récepteur disparaît ou se déconnecte | Vérifiez le signal Wi-Fi, la congestion, l’itinérance, les changements d’adresse et les délais d’expiration des sessions du pare-feu. Si la découverte expire, examinez la gestion de la multidiffusion et l’espionnage IGMP comme indiqué ci-dessous |
| Impossible de rejoindre le réseau | Vérifiez le DHCP et la sécurité Wi-Fi prise en charge. Les appareils de diffusion Google ne prennent pas en charge la connexion via un portail captif ; la prise en charge d’enterprise/802.1X dépend du récepteur. Utilisez un réseau pris en charge ou une option Ethernet. [6] |
3. Paramètres recommandés et vérifications de diagnostic
Espionnage IGMP - recommandé lorsque la conception du réseau le prend en charge. Il peut réduire la multidiffusion
inutile. Suivez les recommandations du fournisseur du commutateur/point d’accès et vérifiez le fonctionnement du querier lorsque cela est nécessaire. Si la découverte disparaît, désactivez brièvement l’espionnage sur le VLAN de test concerné, effectuez un nouveau test, puis réactivez-le et corrigez la configuration de multidiffusion. [7]
Proxy / inspection SSL - diagnostic. Évitez d’exiger un proxy authentifié non pris en charge. Si HTTPS échoue, testez une
exclusion propre au récepteur du proxy et de l’inspection SSL/TLS ; utilisez le résultat pour définir une exception appropriée. [4]
UPnP - pas une exigence générale en entreprise. N’activez pas le mappage automatique des ports du routeur comme solution générale. Configurez explicitement les chemins de découverte et de trafic requis.
4. Isoler le réseau lors d’un test simple
1. Placez les deux appareils sur le même VLAN/sous-réseau de test ou sur un réseau de test simple et sans restriction, avec un accès Internet et l’isolation des clients désactivée.
2. Supprimez du chemin de test le filtrage inter-VLAN, le proxy/l’inspection et les effets du VPN. Réessayez la découverte, la connexion et la mise en miroir avec les mêmes appareils et la même application.
3. Si cela fonctionne, comparez les règles de découverte, de routage et de filtrage du réseau géré. Si le problème persiste, vérifiez la configuration de l’appareil/de l’application et essayez un autre émetteur. Restaurez les modifications de test. [4]
Le problème persiste ? Communiquez au support : le modèle/logiciel du récepteur, le système d’exploitation/l’application de l’émetteur, les deux adresses IP/VLAN, le symptôme exact et l’heure, les journaux de pare-feu pertinents ainsi que le résultat du test d’isolation.
Références techniques (cliquer pour ouvrir) | Révisé le 15 septembre 2026
[1] Google : isolation du point d’accès/client [2] Google : dépannage de la découverte [3] Cisco : passerelle mDNS [4] Google : exigences réseau de Cast Moderator [5] Google : autorisation Réseau local [6] Google : dépannage de la connexion Wi-Fi [7] Cisco : conception et dépannage mDNS