Outils réseau : DNS, WebRTC, test de débit et IP

La page des outils réseau est un plan de travail de connexion à quatre panneaux. Connexion lit l'IP publique et la localisation que voient les services distants, ainsi que des détails d'appareil qui n'ont pas besoin du réseau. Recherche DNS envoie des requêtes DNS-over-HTTPS à Cloudflare ou Google et affiche les enregistrements de réponse. WebRTC collecte les candidats ICE et montre ce qu'une connexion pair à pair exposerait. Test de débit mesure latence, débit descendant et débit montant contre les points de terminaison de Cloudflare. Rien n'est installé ; le calcul au clavier reste dans la calculatrice standard.

更新 2026-10-016 个来源约 5 分钟读完

Comment utiliser les quatre panneaux

Ouvrez le panneau.Chaque panneau a sa propre page dans le groupe Réseau : /data/netlab (Connexion), /data/netlab/dns, /data/netlab/webrtc, /data/netlab/speed.
Connexion.Les cartes de trace Cloudflare donnent l'IP, la localisation, le colo de bord, TLS, HTTP et WARP ; le bloc ipwho.is ajoute pays, ville, FAI et ASN ; Infos locales fonctionne sans réseau, les deux autres blocs en ont besoin.
Recherche DNS.Saisissez un domaine, choisissez l'un des huit types d'enregistrement (A, AAAA, CNAME, MX, TXT, NS, SOA, CAA) et un fournisseur, ou Comparer pour lancer les deux, puis Requêter. Les réponses affichent Nom, Type, TTL et Données ; NOERROR signifie que le nom a été résolu, NXDOMAIN qu'il n'existe pas.
WebRTC.Appuyez sur Démarrer le test ; le tableau des candidats se remplit à mesure que le navigateur trouve des adresses, étiquetées privées, publiques, IPv6 ou mDNS.
Test de débit.Appuyez sur Démarrer le test ; le bouton devient Abandonner pendant que latence, téléchargement et envoi s'exécutent, avec statistiques de latence, débit descendant, octets téléchargés et débit montant. Une exécution complète déplace environ 50 MB.

Exemples calculés

Les relevés ci-dessous ont été capturés en une session ; les TTL décrémentent, donc une nouvelle requête renvoie des nombres différents.

Un MX nul. Domaine example.com, type MX, fournisseur Cloudflare : statut NOERROR ; une ligne — example.com, MX, TTL 300, données 0 .. Un 0 . isolé est un MX nul (RFC 7505) : le nom n'accepte volontairement pas de courrier.
Un nom inexistant. Domaine no-such-host.invalid, type A : statut NXDOMAIN, le tableau remplacé par Aucun enregistrement.
Une chaîne d'alias. Domaine www.wikipedia.org, type A : lignes www.wikipedia.org CNAME TTL 86055 données dyna.wikimedia.org., puis dyna.wikimedia.org A TTL 16 données 103.102.166.224 — une requête A peut porter une ligne CNAME.
Ce qu'une page pair à pair pourrait voir. WebRTC démarré, les cartes affichent IP locales masquées via mDNS ? oui ✓ et Candidats 2 ; les lignes étaient host · local avec un badge mDNS et srflx · public (STUN) avec un badge public, et l'adresse srflx 103.151.173.97 correspondait à l'IP de trace de Connexion. Avec STUN injoignable : aucun détecté et Candidats 1.

Comment les panneaux atteignent le réseau

Connexion fait deux requêtes HTTPS ordinaires, donc suit tout proxy HTTP du chemin ; l'IP de trace est celle qu'a vue le bord de Cloudflare, et le bloc de géolocalisation échoue indépendamment (une session a montré Request failed: HTTP 429).
Recherche DNS envoie la question en requête HTTPS au résolveur choisi (DNS-over-HTTPS), en contournant les réglages DNS de l'appareil ; deux résolveurs peuvent avoir des réponses en cache différentes, d'où Comparer.
WebRTC collecte les candidats ICE : host est local et souvent remplacé par un nom mDNS .local, srflx est l'adresse vue par un serveur STUN, et relay nécessite un serveur TURN que ce panneau ne configure pas.
Test de débit chronomètre des charges générées contre speed.cloudflare.com ; ses échantillons de latence sont des allers-retours HTTPS, pas des pings.

Limites

Les relevés appartiennent au moment.: Latence, gigue et débit dépendent de l'appareil, du Wi-Fi, du FAI et du bord distant, donc deux exécutions diffèrent. Ce sont des mesures, pas des garanties.
Réponses de tiers.: Les résultats DNS viennent du résolveur choisi, pas des réglages DNS de l'appareil, et les TTL en cache décrémentent : un autre appareil peut voir une réponse différente.
Pas un outil de sous-réseau ni de paquets.: Pas de travail CIDR, masque ou VLSM (c'est l'outil de sous-réseau IP), pas de traceroute, capture de paquets, scan de ports ou inspecteur d'en-têtes ; encodage, hachage, JSON et regex vivent dans les outils de développement, et le calcul au clavier dans la calculatrice standard.

Pièges

« DNSSEC: not validated » ne prouve pas qu'une zone n'est pas signée. La carte indique si cette seule réponse du résolveur portait l'indicateur AD. En test, example.com type A affichait "not validated" sur une requête et "AD ✓ validated" sur une autre, tandis que one.one.one.one type A restait non validé.
Un « oui » vert mDNS masque le LAN, pas l'adresse publique. Les candidats host deviennent des noms .local, mais le candidat srflx rapporte toujours l'adresse vue par le serveur STUN, même derrière un VPN.
La case type d'enregistrement fixe la question, pas un filtre. La recherche www.wikipedia.org ci-dessus a renvoyé une ligne CNAME dans une requête A.

Où cela est utile

Diagnostiquer avant d'appeler le support

Les cartes de trace indiquent si le trafic atteint un bord proche, et Infos locales peut alimenter un ticket pendant que le réseau est en panne.

Vérifier le courrier et les changements DNS

Un MX nul (0 .) est un « pas de courrier ici » délibéré. Après un changement d'enregistrement, interrogez le même nom chez les deux fournisseurs pour voir les caches rattraper.

Voir ce qu'une page pair à pair pourrait voir

Un appel vidéo exécute le même échange ICE : srflx est l'adresse qu'un pair distant apprendrait, et la ligne host est ce que mDNS masque.

Références

IETF, RFC 1035: Domain Names — Implementation and Specification, rfc-editor.org （访问日期：2026-10-01）— format des messages DNS, types d'enregistrement et TTL.
IETF, RFC 8484: DNS Queries over HTTPS (DoH), rfc-editor.org （访问日期：2026-10-01）— le transport HTTPS derrière le panneau Recherche DNS.
IETF, RFC 8445: Interactive Connectivity Establishment (ICE), rfc-editor.org （访问日期：2026-10-01）— types de candidats host, réflexif serveur et relay.
IETF, RFC 6762: Multicast DNS, rfc-editor.org （访问日期：2026-10-01）— noms d'hôtes .local.
IETF, RFC 7505: A Null MX No Service Resource Record for Domains That Accept No Mail, rfc-editor.org （访问日期：2026-10-01）— l'enregistrement 0 . de l'exemple.
IETF, RFC 2606: Reserved Top Level DNS Names, rfc-editor.org （访问日期：2026-10-01）— example.com et le nom de test réservé .invalid.