Verwenden Sie diese Checkliste, um das Übertragen in einem verwalteten Schul- oder Unternehmensnetzwerk zu untersuchen. Sender bezeichnet den Laptop, das Smartphone oder
Tablet; Empfänger bezeichnet den Chromecast oder das Cast-fähige Display. Überprüfen Sie das Empfängermodell und die Software: Integrierte Display-
Implementierungen können zusätzliche Anforderungen haben.
Sichtbar bedeutet nicht verbunden. Erkennung, lokale Steuerung und Medien verwenden unterschiedlichen Datenverkehr. Ein Empfänger kann im Cast-Menü erscheinen, während die eigentliche Verbindung blockiert ist.
1. Erforderliche Netzwerkprüfungen
Adressierung und Isolation. Stellen Sie sicher, dass beide Geräte über eine gültige IP-Adresse, Subnetzmaske, Gateway- und DNS-Konfiguration verfügen (DHCP oder unterstützte statische Einstellungen). AP-/Client-Isolation und Gastnetzwerkrichtlinien müssen die Kommunikation zwischen dem vorgesehenen Sender und Empfänger zulassen. [1]
mDNS-/Bonjour-Erkennung. Lassen Sie Abfragen und Antworten für _googlecast._tcp.local zu. Konfigurieren Sie VLAN-übergreifend ein unterstütztes mDNS-Gateway, einen Repeater oder Reflector für die relevanten Netzwerke und den Dienst. Das alleinige Öffnen von UDP 5353 überträgt die link-lokale Erkennung nicht über Subnetze hinweg. [2, 3]
Routing und Rückverkehr. Überprüfen Sie VLAN-übergreifend die Routen in beide Richtungen. Erlauben Sie die lokale Steuerung und Medien über Netzwerk- und Endpunkt-Firewalls hinweg, einschließlich zustandsbehaftetem Rückverkehr. Bevorzugen Sie zwischen den Cast-Netzwerken einen gerouteten Pfad ohne NAT. [4]
Berechtigungen des Senders – erforderlich, wenn dazu aufgefordert wird. Aktivieren Sie unter iOS/iPadOS 14+ und macOS 15+ für die Cast-App oder Chrome die Option „Datenschutz und Sicherheit“ > „Lokales Netzwerk“, und öffnen Sie die App anschließend erneut. [5]
2. Zu überprüfender Datenverkehr
Erforderlich = für die angegebene Funktion notwendig. Diagnose = ein zeitlich begrenzter Test, beschränkt auf die Testgeräte. Lokale Regeln gelten innerhalb des Netzwerks; ausgehende Regeln gelten für Internet- oder Infrastrukturdienste.
| Datenverkehr / Ports | Pfad | Anforderung / Zweck |
|---|---|---|
|
mDNS UDP 5353 |
Lokale Erkennung |
Für die standardmäßige Erkennung erforderlich. IPv4-Multicast 224.0.0.251; IPv6 ff02::fb, sofern verwendet. Überprüfen Sie die Weiterleitung über WLAN und kabelgebundene Netzwerke. [2, 3] |
|
Lokale Steuerung TCP 8008-8009 |
Vom Sender zum Empfänger |
Für die standardmäßige Cast-Steuerung erforderlich. Lassen Sie Antworten über hergestellte Verbindungen zu. Bestätigen Sie modellspezifische Ports. [4] |
|
Medien / Spiegelung UDP, dynamische Ports |
Sender und Empfänger, beide Richtungen |
Erforderlich: Mediendatenverkehr muss passieren können. Diagnose: Lassen Sie vorübergehend UDP 1-65535 zwischen den Testgeräten zu; siehe Umfang weiter unten. [4] |
|
HTTP / HTTPS TCP 80 / 443 |
Vom Sender / Empfänger zu den erforderlichen Diensten |
Erforderlich, sofern für die Einrichtung verwendet, für Updates und Onlineinhalte. Überprüfen Sie die Servicedomains und alle zusätzlichen Anwendungsports. |
|
DNS UDP und TCP 53 |
Von den Geräten zu funktionierenden DNS-Resolvern |
Erforderlich: erfolgreiche Namensauflösung. Überprüfen Sie blockierte Abfragen und verifizieren Sie eine gerätespezifische Verwendung externer Resolver. |
|
NTP UDP 123 |
Vom Empfänger zu seinem Zeitdienst |
Bei Verwendung von NTP erforderlich. Die korrekte Zeit wird für die Zertifikatvalidierung benötigt; überprüfen Sie Zeit und Synchronisierung. |
Portumfang: Google gibt für Cast Moderator ausdrücklich UDP 1-65535 an. Bestätigen Sie bei anderen Empfängern die dauerhaften Medienregeln mit dem
Hersteller. Gehen Sie nicht davon aus, dass TCP/UDP 32768-61000 universell gilt. Cast Moderator verwendet außerdem eine andere Erkennungsmethode als standardmäßiges
mDNS-basiertes Cast. [4]
Fehlerhaften Schritt finden
Symptome und praktische Prüfungen
| Symptom | Durchzuführende Prüfungen |
|---|---|
| Empfänger ist nicht sichtbar | Bestätigen Sie, dass der Empfänger online und Cast aktiviert ist. Überprüfen Sie AP-/Client-Isolation, mDNS-Dienstankündigungen, VLAN-Gateway-Richtlinien und die Berechtigung des Senders für das lokale Netzwerk. Versuchen Sie es mit einem anderen Sender oder einer anderen Cast-fähigen App. [1-3, 5] |
| Sichtbar, aber keine Verbindung möglich | Überprüfen Sie die Route zur angekündigten IP-Adresse des Empfängers, TCP 8008-8009, Firewall-/ACL-Protokolle und den Rückverkehr. Prüfen Sie NAT sowie VPN- oder Endpunkt-Firewallregeln des Senders. Die Erkennung allein bestätigt diese Pfade nicht. [4] |
| Verbindung wird hergestellt, aber Spiegelung schlägt fehl | Überprüfen Sie die Filterung von UDP-Mediendatenverkehr in beide Richtungen. Führen Sie den eingeschränkten UDP-Diagnosetest auf Seite 1 durch. Überprüfen Sie auf dem Sender die Berechtigung für Bildschirmaufnahmen, sofern erforderlich. Vergleichen Sie einen anderen Sender bzw. eine andere App. |
| Onlineinhalte funktionieren nicht | Überprüfen Sie den Internetzugriff direkt vom Empfänger, DNS-Antworten, TCP 80/443 sowie die korrekte Zeit/NTP. Prüfen Sie Domainfilterung, Proxy-Authentifizierung und SSL-/TLS-Inspektion; testen Sie eine gezielte Ausnahme. |
| Verschwindet oder wird getrennt | Überprüfen Sie WLAN-Signal, Überlastung, Roaming, Adressänderungen und Zeitüberschreitungen von Firewall-Sitzungen. Wenn die Erkennung abläuft, überprüfen Sie die Multicast-Verarbeitung und IGMP-Snooping wie unten beschrieben |
| Netzwerkbeitritt nicht möglich | Überprüfen Sie DHCP und die unterstützte WLAN-Sicherheit. Google-Streaminggeräte unterstützen keine Anmeldung an Captive Portals; die Unterstützung von Enterprise-/802.1X hängt vom Empfänger ab. Verwenden Sie ein unterstütztes Netzwerk oder eine Ethernet-Option. [6] |
3. Empfohlene Einstellungen und Diagnoseprüfungen
IGMP-Snooping – empfohlen, sofern vom Netzwerkdesign unterstützt. Es kann unnötige Multicast-Überflutung reduzieren. Befolgen Sie die Empfehlungen des Switch-/AP-Anbieters und überprüfen Sie, sofern erforderlich, den Betrieb des Querier. Wenn die Erkennung verschwindet, deaktivieren Sie Snooping im betroffenen Test-VLAN kurzzeitig, führen Sie den Test erneut durch, aktivieren Sie es anschließend wieder und korrigieren Sie die Multicast-Konfiguration. [7]
Proxy-/SSL-Inspektion – Diagnose. Vermeiden Sie die Anforderung eines nicht unterstützten authentifizierten Proxys. Wenn HTTPS fehlschlägt, testen Sie eine empfängerspezifische Ausnahme von Proxying und SSL-/TLS-Inspektion; verwenden Sie das Ergebnis, um eine geeignete Ausnahme zu definieren. [4]
UPnP – keine pauschale Enterprise-Anforderung. Aktivieren Sie die automatische Portzuordnung des Routers nicht als allgemeine Lösung. Konfigurieren Sie die erforderlichen Erkennungs- und Datenverkehrspfade ausdrücklich.
4. Netzwerk in einem einfachen Test isolieren
1. Platzieren Sie beide Geräte im selben Test-VLAN/Subnetz oder in einem einfachen uneingeschränkten Testnetzwerk mit Internetzugriff und deaktivierter Client-Isolation.
2. Entfernen Sie Inter-VLAN-Filterung, Proxy-/Inspektionseffekte und VPN-Einflüsse aus dem Testpfad. Wiederholen Sie die Erkennung, Verbindung und Spiegelung mit denselben Geräten und derselben App.
3. Wenn es funktioniert, vergleichen Sie die Erkennungs-, Routing- und Filterrichtlinien des verwalteten Netzwerks. Wenn es weiterhin fehlschlägt, überprüfen Sie die Geräte-/App-Einrichtung und versuchen Sie es mit einem anderen Sender. Stellen Sie die Teständerungen wieder her. [4]
Weiterhin ungelöst? Teilen Sie dem Support Folgendes mit: Empfängermodell/-software, Betriebssystem/App des Senders, beide IPs/VLANs, genaues Symptom und Zeitpunkt, relevante Firewall-Protokolle sowie das Ergebnis des Isolationstests.
Technische Referenzen (zum Öffnen anklicken) | Überprüft am 15. September 2026
[1] Google: AP-/Client-Isolation [2] Google: Fehlerbehebung bei der Erkennung [3] Cisco: mDNS-Gateway [4] Google: Netzwerkanforderungen für Cast Moderator [5] Google: Berechtigung für das lokale Netzwerk [6] Google: Fehlerbehebung bei der WLAN-Verbindung [7] Cisco: mDNS-Design und Fehlerbehebung