# Erreur réseau (/fr/docs/web-security/reporting-api/reports/network-error)



Un report `network-error` décrit une requête qui a échoué (ou réussi, en cas
d'échantillonnage) au niveau réseau : un échec DNS, une erreur TCP ou TLS, une
connexion réinitialisée ou une erreur HTTP. Comme ces échecs n'atteignent souvent jamais
vos propres journaux, [Network Error Logging (NEL)](/fr/docs/web-security/policies/network-error-logging) est le moyen de les voir du point
de vue du client.

<Callout type="warn" title="Expérimental, et lié à l'ancien header">
  NEL est propre à Chromium et c'est le seul type de report qui requiert encore le header déprécié `Report-To`. `Reporting-Endpoints` ne délivre pas NEL. Voir [Network Error Logging](/fr/docs/web-security/policies/network-error-logging).
</Callout>

## Quand le navigateur l'envoie [#quand-le-navigateur-lenvoie]

Lors de l'échec d'une requête, ou lors d'une requête réussie quand le
`success_fraction` configuré l'échantillonne. Les paramètres `failure_fraction` et
`success_fraction` du header `NEL` contrôlent ce qui est reporté, donc les échecs sont
généralement capturés à plein taux et les succès échantillonnés légèrement, voire pas du
tout.

## Configuration [#configuration]

```http
Report-To: {"group":"nel-group","max_age":31536000,"endpoints":[{"url":"https://<Endpoint-ID>.report.centralcsp.com"}]}
```

```http
NEL: {"report_to":"nel-group","max_age":31536000,"include_subdomains":true,"failure_fraction":1.0}
```

## Exemple de payload [#exemple-de-payload]

```json
{
  "type": "network-error",
  "age": 20,
  "url": "https://example.com/bad-request",
  "user_agent": "Mozilla/5.0 ...",
  "body": {
    "sampling_fraction": 1,
    "referrer": "https://example.com/previous-page",
    "server_ip": "192.0.2.172",
    "protocol": "http/1.1",
    "method": "POST",
    "request_headers": {},
    "response_headers": {},
    "status_code": 400,
    "elapsed_time": 338,
    "phase": "application",
    "type": "http.error"
  }
}
```

## Référence des champs [#référence-des-champs]

| Champ               | Signification                                                                              |
| ------------------- | ------------------------------------------------------------------------------------------ |
| `sampling_fraction` | Le taux auquel ce résultat a été échantillonné (0 à 1).                                    |
| `referrer`          | Le referrer de la requête échouée.                                                         |
| `server_ip`         | L'IP du serveur résolue, ou `""` si aucune.                                                |
| `protocol`          | Le protocole utilisé, par exemple `http/1.1`.                                              |
| `method`            | La méthode HTTP.                                                                           |
| `request_headers`   | Les headers de requête que la politique `NEL` a choisi d'inclure, indexés par nom.         |
| `response_headers`  | Les headers de réponse que la politique `NEL` a choisi d'inclure, indexés par nom.         |
| `status_code`       | Le statut HTTP, ou `0` quand il n'y a pas eu de réponse.                                   |
| `elapsed_time`      | Temps jusqu'à l'échec, en millisecondes.                                                   |
| `phase`             | Où elle a échoué : `dns`, `connection` ou `application`.                                   |
| `type`              | Le code d'erreur précis, par exemple `dns.name_not_resolved`, `tcp.refused`, `http.error`. |

La `phase` est le triage le plus rapide : `dns` pointe vers la résolution de nom,
`connection` vers TCP ou TLS, et `application` vers une erreur de niveau HTTP.

## Comment le recevoir [#comment-le-recevoir]

Associez le header `NEL` à un groupe `Report-To` (NEL ne fonctionne pas avec
`Reporting-Endpoints`). Pointez l'endpoint du groupe vers CentralCSP pour collecter le
[flux network-error](/fr/docs/platform/monitoring/nel) au côté de vos autres reports.

## Ce qu'il vous apprend sur la sécurité [#ce-quil-vous-apprend-sur-la-sécurité]

La plupart des erreurs réseau sont des signaux de disponibilité, mais les schémas
comptent : un groupe d'échecs TLS ou de certificat depuis une même région peut indiquer
une interception ou un portail captif, et une vague d'échecs DNS ou de connexion est un
signal de disponibilité et d'intégrité qui mérite d'être investigué avant que les
utilisateurs ne se plaignent.

## Pièges [#pièges]

Les noms de champs du body sont en snake\_case, contrairement aux reports de violation de
politique en camelCase. NEL est réservé à HTTPS, et n'est pas délivré via
`Reporting-Endpoints`, seulement via l'ancien header `Report-To`, qui est le seul endroit
où ce header est encore requis.

## Prise en charge par les navigateurs [#prise-en-charge-par-les-navigateurs]

Navigateurs basés sur Chromium uniquement (Chrome, Edge, Opera). Firefox et Safari
n'implémentent pas NEL, et Mozilla maintient une position défavorable au standard en
invoquant la confidentialité.

## Voir aussi [#voir-aussi]

* [Network Error Logging (NEL)](/fr/docs/web-security/policies/network-error-logging)
* [header Report-To](/fr/docs/web-security/reporting-api/headers/report-to)
* [Report-To vs Reporting-Endpoints](/fr/docs/web-security/reporting-api/concepts/report-to-vs-reporting-endpoints)
* [Monitoring NEL dans CentralCSP](/fr/docs/platform/monitoring/nel)
* [Le format de livraison des rapports](/fr/docs/web-security/reporting-api/concepts/report-delivery-format)

## Sources [#sources]

* [MDN, Network Error Logging](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Network_Error_Logging)
* [W3C, Network Error Logging](https://www.w3.org/TR/network-error-logging/)
* [web.dev, Network Error Logging](https://web.dev/articles/network-error-logging)