# 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 exige encore le header déprécié `Report-To`. `Reporting-Endpoints` n'achemine 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é : en général, les échecs
sont capturés à plein taux et les succès seulement échantillonnés, 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) aux côtés 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 leurs 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é qu'il vaut mieux creuser 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 ne passe pas par
`Reporting-Endpoints`, seulement par l'ancien header `Report-To` : c'est le seul cas
où ce header reste nécessaire.

## 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, au nom
de 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)