# Erreurs réseau (/fr/docs/platform/monitoring/nel)





Les requêtes en échec vers votre site, signalées via Network Error Logging.

La raison d'y prêter attention : vos logs serveur ne contiennent que les requêtes qui ont atteint votre serveur. Voici celles qui ne l'ont pas atteint.

<img alt="Le tableau Requêtes en échec, avec chaque type d'erreur, sa phase et l'origine qui a échoué" src="__img0" width="1359" height="414" />

## Colonnes [#colonnes]

| Colonne               | Signification                                         |
| --------------------- | ----------------------------------------------------- |
| Type                  | Le type d'erreur retenu par le navigateur             |
| Phase                 | Où la requête a échoué, DNS, connexion ou application |
| Origine de la requête | L'origine demandée                                    |
| Navigateurs           | Les navigateurs qui l'ont signalée                    |
| Reports               | Les reports regroupés dans cette ligne                |
| Dernière occurrence   | L'occurrence la plus récente                          |

Pas de colonne Disposition : une erreur réseau n'est pas le résultat d'une politique.

Le détail descend au niveau de la requête, avec **URL de la requête**, **IP du serveur**, **Protocole**, **Méthode** et **Code de statut**. Un code de statut vide signifie que la réponse n'est jamais allée assez loin pour en avoir un.

## Utiliser Phase pour orienter le problème [#utiliser-phase-pour-orienter-le-problème]

Le filtre **Toutes les phases** a trois valeurs fixes, et chacune désigne une équipe différente.

| Phase         | A échoué à           | Signifie en général                                                                                      |
| ------------- | -------------------- | -------------------------------------------------------------------------------------------------------- |
| `dns`         | La résolution de nom | Une erreur de configuration DNS, un enregistrement expiré, ou un résolveur en difficulté dans une région |
| `connection`  | TCP ou TLS           | Des erreurs de certificat, une négociation de protocole, un pare-feu ou un souci de peering              |
| `application` | Après la connexion   | La réponse elle-même a échoué ou a été tronquée                                                          |

Filtrez d'abord par phase. Un groupe `dns` et un groupe `application` n'ont rien à voir l'un avec l'autre et vont à des personnes différentes.

## Lire la géographie [#lire-la-géographie]

Des erreurs réseau concentrées sur une région ou un réseau, ce n'est en général pas à vous de les corriger directement, mais c'est à vous de les connaître. Un résolveur en panne dans un pays produit une panne totale pour ces utilisateurs et un silence complet dans votre propre monitoring.

Recoupez avec **IP du serveur** dans la vue de détail quand vous exploitez plusieurs points de présence. Une seule IP à l'origine de tous les échecs restreint immédiatement la recherche.

## Les compteurs sont des planchers [#les-compteurs-sont-des-planchers]

Un navigateur ne peut livrer un report que lors d'une connexion réussie ultérieure. Les utilisateurs qui ne reviennent jamais ne remontent rien. Le nombre réel d'échecs est donc supérieur à ce que vous voyez, et l'écart est maximal pendant une panne totale, quand le reporting lui-même ne passe plus.

Les tendances ont du sens, les totaux absolus non. Un trou dans le graphique pendant un incident est une preuve de l'incident, pas la preuve qu'il a cessé.

## Ajuster le volume [#ajuster-le-volume]

NEL ne remonte rien tant que `NEL` et `Report-To` ne sont pas présents sur la réponse du document. `Reporting-Endpoints` ne transporte pas NEL, donc le header `Report-To` doit être là même si le reste de votre reporting ne s'en sert plus. Le [vérificateur de configuration de la Reporting API](/tools/reporting-api) les relit depuis une URL publique, c'est le moyen le plus rapide d'écarter cette cause quand cette page reste vide.

`failure_fraction` dans votre header `NEL` contrôle la proportion des échecs que les navigateurs signalent. Le header généré la fixe à `1.0`, c'est-à-dire tous :

```http
NEL: {"report_to":"default","max_age":10886400,"failure_fraction":1.0}
```

Sur un site à fort trafic, cela peut consommer l'essentiel de votre quota de reports. Baissez-la pour échantillonner les échecs au niveau du navigateur plutôt qu'à l'ingestion. Voir [Consommation et limites](/fr/docs/platform/websites/usage-and-limits).

## Étapes suivantes [#étapes-suivantes]

* [Crashs](/fr/docs/platform/monitoring/crash)
* [Référence Network Error Logging](/fr/docs/web-security/policies/network-error-logging)
