网络错误日志记录

当 用户代理尝试通过网络为某个请求进行HTTP 网络获取资源时，就会发生一次网络请求。

如果已知用户代理处于离线状态（即 navigator. onLine 返回 false），请求 不得产生 网络请求。

如果请求因 混合内容 或 CORS 失败被阻止，该 请求 不得产生 网络请求。任何 CORS 预检请求 必须产生它自己的 网络请求。

无论采用哪种 fetch 算法和底层应用、传输协议，服务一次 网络请求均包含以下几个阶段：

1. DNS 解析：用户代理使用域名系统 [RFC1034] 将域名解析为可为该域服务 HTTP 请求的 IP 地址 的 服务器。
2. 安全连接建立：用户代理与 服务器 建立连接，并在此连接上建立安全通道。
3. 请求和响应传输：安全通道建立后，用户代理可以发送 HTTP 请求，并从 服务器 接收 响应。

唯一必需的阶段是请求和响应传输；其他阶段对于每个 网络请求可能不是必需的。例如，用户代理本地可以缓存 DNS 结果，从而免除后续对同一域名的 DNS 解析。同样，HTTP 持久连接允许打开一个连接后为同一分区密钥的多个请求复用。但如果多个阶段依次发生，其顺序应如上。

如果用户代理能够从服务器接收有效 HTTP 响应，且该响应状态码不是 4xx 或 5xx，则此 网络请求被认为是成功的。

如果未被判定为 成功，则该 网络请求为失败。

导致某 网络请求失败的错误状态被称为网络错误。

每个 网络错误都有一个类型，为字符串。

每个 网络错误都有一个 阶段，用于描述错误发生在哪一阶段：

dns

错误发生在 DNS 解析阶段

connection

错误发生在 安全连接建立阶段

application

错误发生在 请求和响应传输阶段

6. 预定义网络错误类型中定义了若干预定义的 网络错误类型。

网络错误报告 是一个 Reporting API 报告，用于描述 一个 网络错误。

网络错误报告的 报告类型 是 network-error。

网络错误报告 不会 暴露给 ReportingObserver。

NEL 策略 用于指示用户代理是否要收集发往某个 网络请求的 origin 的报告，如果需要，则指定报告发送目的地。 NEL 策略 通过 HTTP 响应头 下发给用户代理。

每个 NEL 策略都有一个接收 IP 地址，即用户代理收到 NEL 策略时服务器的 IP 地址。

每个 NEL 策略有一个源点。

每个 NEL 策略有一个 子域 标志，值可为 include 或 exclude。

每个 NEL 策略有一个请求头列表（policy request headers） 和响应头列表（policy response headers），每个列表中的元素均为头名称。

每个 NEL 策略有一个 报告组，即报告将发送到的 Reporting 终端组名称。

每个 NEL 策略有一个 ttl，表示该策略有效的秒数。

每个 NEL 策略有一个 创建时间，即用户代理收到策略的时间戳。

当从创建时间到挂钟的当前不安全时间 时长大于 172800 秒（48 小时）时，NEL 策略为过时。

当从创建时间到挂钟的当前不安全时间 时长大于其 ttl 时，NEL 策略为已过期。

期望服务大量流量的源点可能无法承载为其所有 网络请求生成的完整 NEL 报告。源点可定义采样率限制每个用户代理上报的 NEL 报告数量。由于成功请求通常远多于失败请求，源点可为不同情形指定不同的采样率。

每个 NEL 策略有一个 成功采样率，值在 0.0–1.0 之间。

每个 NEL 策略有一个 失败采样率，值在 0.0–1.0 之间。

合规的用户代理必须提供一个策略缓存，即用于保存 NEL 策略 的存储机制，键为 (网络分区密钥, 源点) 二元组。

此存储机制为不透明、厂商自定义且不暴露给 Web，但必须提供下列方法，供本文档定义的算法使用：

• 插入、更新和删除 NEL 策略。
• 检索某个 源点和 网络分区密钥下的 NEL 策略（如有）。
• 清空缓存。

NEL 响应头用于将 origin 的 NEL 策略传递给用户代理。NEL 头的 ABNF（扩展巴科斯-诺尔范式）[RFC5234] 语法如下：

NEL = json-field-value

该响应头的值按照 json-field-value 的定义作为一个 JSON 对象数组来解释。数组中的每个对象为该 origin 定义一个 NEL 策略。用户代理必须只处理数组中的第一个有效策略，忽略数组中的其余策略。

用户代理必须忽略任何未知或无效的字段或值，凡不符合本规范定义语法的均忽略。一个有效的NEL响应头必须至少包含一个符合本规范所有 “必需” 字段的对象。

为防止通过脚本攻击劫持错误上报，对于通过 meta 元素指定的 NEL头，用户代理必须忽略。NEL 策略必须通过NEL 响应头下发。

给定一个 网络请求（request）及其对应的 响应（response），本算法将从中提取 NEL 策略，并据此更新 策略缓存。

1. 若满足以下任一条件，则终止：
   • 对 request 的 origin 是否可信 算法执行结果不是 Potentially Trustworthy。
   • response 不包含名为 NEL 的 响应头。
2. 令 origin 为 request 的 origin。
3. 令 key 为 确定网络分区密钥算法在 request 的 reserved client 上的结果。
4. 令 header 为名为 NEL 的 响应头的值。
5. 令 list 为 [HTTP-JFV] 4 节算法在 header 上的结果。若出错或结果为空则终止。
6. 令 item 为 list 的第一个元素。
7. 若 item 未包含 max_age 字段，或该字段值不是数字，则终止。
8. 若 item 的 max_age 字段值为 0，则移除 策略缓存中 origin 为 origin 的任何 NEL 策略，并跳过余下步骤。
9. 若 item 未包含 report_to 字段，或该字段不是字符串，则终止。
10. 若 item 含有 success_fraction 字段，且其值不在 [0.0, 1.0] 范围，则终止。
11. 若 item 含有 failure_fraction 字段，且其值不在 [0.0, 1.0] 范围，则终止。
12. 若 item 含有 request_headers 字段，其值非数组或数组中有非字符串元素，则终止。
13. 若 item 含有 response_headers 字段，其值非数组或数组中有非字符串元素，则终止。

14. 令 policy 为新建的 NEL 策略，其属性如下：

    接收 IP 地址

    用户代理收到 response 时 服务器 IP 地址

    编者注

    [FETCH] 中需要更明确地传递。

    origin

    origin

    子域 标志

    若 item 有 include_subdomains 且值为 true，则为 include，否则为 exclude

    请求头

    item 的 request_headers 字段值

    响应头

    item 的 response_headers 字段值

    报告组

    item 的 report_to 字段值

    ttl

    item 的 max_age 字段值

    创建时间

    挂钟 的 当前不安全时间

    成功采样率

    item 的 success_fraction 字段值，如无则为 0.0

    失败采样率

    item 的 failure_fraction 字段值，如无则为 1.0

15. 若 策略缓存中已存在 (key, origin) 项，则以 policy 替换；否则插入 policy 到 (key, origin)。

给定一个 网络请求（request），本算法用于确定在 策略缓存中，应为该 网络请求生成报告采用哪个 NEL 策略。

1. 令 origin 为 request 的 origin。
2. 令 key 为对 request 的 reserved client 执行“确定网络分区密钥”算法的结果。
3. 如果 (key, origin) 项存在于 策略缓存中：
   1. 令 policy 为该项。
   2. 如果 policy 没有 过期，则返回它。
4. 对于 origin 的每个 父origin（即 超级域匹配）：
   1. 如果 (key, parent origin) 项存在于 策略缓存中：
      1. 令 policy 为该项。
      2. 如果 policy 没有 过期 且其 subdomains 标志为 include，则返回它。
5. 返回 无策略。

给定一个 网络请求（request）和 NEL 策略（policy），本算法根据策略指示从请求中提取头部值。

1. 令 headers 为新建的空 ECMAScript 对象。
2. 对于 policy 的 请求头 列表中的每个 header name：
   1. 如果 request 的 头部列表不包含 header name，则跳至下一个 header name。
   2. 令 values 为空 ECMAScript 列表。
   3. 对于 request 的 头部列表中 名称为 header name 的每个 header，将 header 的 值加入 values。
   4. 在 headers 上新增属性，其名为 header name，值为 values。
3. 返回 headers。

给定 响应（response）和 NEL 策略 （policy），本算法按照策略指示从响应中提取头部值。

1. 令 headers 为新建的空 ECMAScript 对象。
2. 对于 policy 的 响应头 列表中的每个 header name：
   1. 如果 response 的 头部列表 不包含 header name，则跳至下一个 header name。
   2. 令 values 为空 ECMAScript 列表。
   3. 对 response 的 头部列表中名称为 header name 的每个 header，将 header 的 值加入 values。
   4. 在 headers 上新增属性，其名为 header name，值为 values。
3. 返回 headers。

给定 网络请求（request）及其对应的 响应（response），如果有匹配的 NEL 策略要求报告，则本算法为 request 生成报告并返回报告及 NEL 策略，否则返回 null。

1. 如果对 request 的 origin 是否可信算法结果不是 Potentially Trustworthy，返回 null。
2. 令 origin 为 request 的 origin。
3. 令 policy 为对 request 调用5.1 为请求选择策略的结果。若 policy 为无策略，返回 null。
4. 确定本次请求的有效采样率：
   • 如果 request 成功，令 sampling rate 为 policy 的 成功采样率。
   • 如果 request 失败，令 sampling rate 为 policy 的 失败采样率。
5. 判断本次请求是否应上报。令 roll 为 0.0~1.0 间的随机数。如 roll > sampling rate，返回 null。
6. 令 report body 为新 ECMAScript 对象，包含以下属性：[ECMA-262]

   sampling_fraction

   sampling rate

   elapsed_time

   从资源拉取开始到用户代理完成或中止所用的时间（毫秒数）。

   phase

   若 request 失败，则为其 阶段；如果 request 成功，则为 "application"。

   type

   若 request 失败，则为其 类型；若 request 成功，为 "ok"。

7. 如果 report body 的 phase 属性不是 dns，则附加以下属性：

   server_ip

   用户代理实际发送请求到的服务器的 IP 地址（如有）；否则为空字符串。

   • IPv4 用点分十进制表示。
   • IPv6 用 x:x:x:x:x:x:x:x 形式表示。

   protocol

   拉取资源使用的网络协议（以 ALPN Protocol ID 标识，如有）；否则为 ""。

8. 如果 report body 的 phase 不是 dns 或 connection，则附加以下属性：

   referrer

   由 referrer policy 以及 client 决定的 request 的 referrer。

   method

   request 的 请求方法。

   request_headers

   对 request 和 policy 执行5.2 提取请求头的结果。

   response_headers

   对 response 和 policy 执行5.3 提取响应头的结果。

   status_code

   HTTP 响应的状态码（如有）；否则为 0。

9. 如果 origin 不等于 policy 的 origin，且 policy 的 subdomains 标志为 include，并且 report body 的 phase 不是 dns， 返回 null。
   注

   此步骤确保子域NEL 策略只能用于在策略源点的子域上的DNS 解析阶段生成报告。详情见9. 隐私注意事项。

10. 如果 report body 的 phase 不是 dns，且 report body 的 server_ip 属性非空且不等于 policy 的 接收 IP 地址：
    1. 令 report body 的 phase 设为 dns。
    2. 令 report body 的 type 设为 dns.address_changed。
    3. 清空 report body 的 request_headers、response_headers、status_code 和 elapsed_time 属性。
    4. 断言：report body 内所有在 DNS 解析期间不可用的信息都已被清除。
    注

    当服务器与策略的 IP 地址不匹配时，此步骤会“降级”NEL 报告，仅允许其携带 DNS 解析相关信息。这样做目的是隐私保护，确保最后只有域名持有者能收到该报告，否则不可追踪到具体服务器。详见 9. 隐私注意事项 和 7.5 多 IP 地址源站。

11. 如果 policy 已经 过时，则从 策略缓存中删除 policy。
12. 返回 report body 与 policy。

给定一份 ECMAScript 对象（report body，通常由 生成网络错误报告返回，随后由调用规范补充）及其匹配的 NEL 策略（policy）和 网络请求（request），本算法负责队列化报告以进行投递。

1. 令 url 为 request 的 URL。

2. 移除 url 的 片段。

3. 如果 report body 的 phase 属性为 dns 或 connection：

   1. 移除 url 的 路径和查询。

4. 以如下参数生成一个网络报告：

   type

   network-error

   data

   report body

   endpoint group

   policy 的 报告组

   url

   对 url 执行 URL 序列化器 的结果。

本节内所有网络错误均发生在DNS 解析阶段，故其phase为 dns。

dns.unreachable

DNS 服务器不可达

dns.name_not_resolved

DNS 服务器有响应，但无法解析该地址

dns.failed

由于非上述原因，请求 DNS 服务器失败

dns.address_changed

指定请求的 origin 的 IP 地址自对应NEL 策略下发以来发生了变更

本节内所有网络错误均发生在安全连接建立阶段，故其phase为 connection。

tcp.timed_out

与服务器的 TCP 连接超时

tcp.closed

TCP 连接被服务器关闭

tcp.reset

TCP 连接被重置

tcp.refused

服务器拒绝建立 TCP 连接

tcp.aborted

TCP 连接被中止

tcp.address_invalid

IP 地址无效

tcp.address_unreachable

IP 地址不可达

tcp.failed

由于非上述原因，TCP 连接失败

tls.version_or_cipher_mismatch

TLS 连接因协议版本或加密套件不匹配而中止

tls.bad_client_auth_cert

TLS 连接因客户端证书无效而中止

tls.cert.name_invalid

TLS 连接因证书名称无效而中止

tls.cert.date_invalid

TLS 连接因证书日期无效而中止

tls.cert.authority_invalid

TLS 连接因签发机构无效而中止

tls.cert.invalid

TLS 连接因证书无效而中止

tls.cert.revoked

TLS 连接因服务器证书已吊销而中止

tls.cert.pinned_key_not_in_cert_chain

TLS 连接因密钥钉扎错误而中止

tls.protocol.error

TLS 连接因 TLS 协议错误而中止

tls.failed

由于非上述原因，TLS 连接失败

本节内所有网络错误均发生在请求和响应传输阶段，故其phase为 application。

http.error

用户代理成功接收到响应，但其状态码为 4xx 或 5xx

http.protocol.error

因 HTTP 协议错误导致连接中止

http.response.invalid

响应为空、长度不符、编码不合法等导致用户代理无法处理响应的情况

http.response.redirect_loop

因检测到重定向循环请求被中止

http.failed

因协议错误导致连接失败（不属于上面的具体情况）

abandoned

用户在请求完成前中止了资源拉取

unknown

错误类型未知

> GET / HTTP/1.1
> Host: example.com

< HTTP/1.1 200 OK
< ...
< Report-To: {"group": "network-errors", "max_age": 2592000,
              "endpoints": [{"url": "https://example.com/upload-reports"}]}
< NEL: {"report_to": "network-errors", "max_age": 2592000}

该 NEL 响应头定义了一个 NEL 策略，指示用户代理将关于 example.com 的网络错误报告发送到名为 network-errors 的 终端组。该策略有效期为 2592000 秒（30 天）。

注意，上述注册仅当响应来自于潜在可信源点时才会成功。

> GET / HTTP/1.1
> Host: example.com

< HTTP/1.1 200 OK
< ...
< NEL: {"max_age": 0}

此 NEL 响应头指示用户代理移除 example.com 的所有现有 NEL 策略。

本节包含 网络错误报告的示例，当用户代理在某个已经注册了NEL 策略的 origin 上遇到网络错误时，用户代理可能会队列化这些报告。我们展示了使用 [REPORTING] API 上传时生成的完整报告载荷；载荷的 body 字段包含 网络错误报告体。

{
  "age": 0,
  "type": "network-error",
  "url": "https://www.example.com/",
  "body": {
    "sampling_fraction": 0.5,
    "referrer": "http://example.com/",
    "server_ip": "2001:DB8:0:0:0:0:0:42",
    "protocol": "h2",
    "method": "GET",
    "request_headers": {},
    "response_headers": {},
    "status_code": 200,
    "elapsed_time": 823,
    "phase": "application",
    "type": "http.protocol.error"
  }
}

该报告表示用户代理尝试从 example.com 导航到 www.example.com，其成功解析为 2001:DB8::42。但虽然用户代理从服务器通过 HTTP/2（h2）协议接收到 200 响应，却在过程中遇到协议错误，最终放弃导航。用户代理在导航开始 823 毫秒后终止导航。最后，在网络错误发生后立即发送本报告，即报告 age 为 0。

{
  "age": 0,
  "type": "network-error",
  "url": "https://widget.com/thing.js",
  "body": {
    "sampling_fraction": 1.0,
    "referrer": "https://www.example.com/",
    "server_ip": "",
    "protocol": "",
    "method": "GET",
    "request_headers": {},
    "response_headers": {},
    "status_code": 0,
    "elapsed_time": 143,
    "phase": "dns",
    "type": "dns.name_not_resolved"
  }
}

上述报告表示用户代理尝试从 https://www.example.com/ 获取 https://widget.com/thing.js，但无法解析 DNS 名称（widget.com），请求在 143 毫秒后被用户代理中止。因先前请求 widget.com 时曾下发有效 NEL 策略，本次请求产生了 网络错误报告。报告上传于错误发生后立即，即 age 为 0。

> GET / HTTP/1.1
> Host: example.com

< HTTP/1.1 200 OK
< ...
< Report-To: {"group": "network-errors", "max_age": 2592000,
              "endpoints": [{"url": "https://example.com/upload-reports"}]}
< NEL: {"report_to": "network-errors", "max_age": 2592000, "include_subdomains": true}

此 NEL 响应头允许 example.com 的所有者检测 DNS 配置错误——例如遗忘添加解析 new-subdomain.example.com 到 IP 地址的新资源记录。当用户代理尝试请求 new-subdomain.example.com 时，可能会生成如下报告：

{
  "age": 0,
  "type": "network-error",
  "url": "https://new-subdomain.example.com/",
  "body": {
    "sampling_fraction": 1.0,
    "server_ip": "",
    "protocol": "http/1.1",
    "method": "GET",
    "request_headers": {},
    "response_headers": {},
    "status_code": 0,
    "elapsed_time": 48,
    "phase": "dns",
    "type": "dns.name_not_resolved"
  }
}

> GET / HTTP/1.1
> Host: example.com

< HTTP/1.1 200 OK
< ...
< Report-To: {"group": "network-errors", "max_age": 2592000,
              "endpoints": [{"url": "https://example.com/upload-reports"}]}
< NEL: {"report_to": "network-errors", "max_age": 2592000, "success_fraction": 1.0,
        "request_headers": ["If-None-Match"], "response_headers": ["ETag"]}
< ETag: 01234abcd

在本例中，example.com 的所有者使用 ETag 响应头标识对应资源的不同版本。用户代理随后可使用 If-None-Match 请求头告知服务器客户端已缓存的资源版本，从而在副本有效时避免生成和下发内容。

通过让该域名的 NEL 响应头包含 request_headers 和 response_headers 字段，浏览器将在 NEL 报告中包含 If-None-Match 请求头和 ETag 响应头的副本，从而让站点所有者追踪缓存策略效果。

基于上述，考虑以下事件流程：

1. 用户代理向 example.com 发送 请求，收到 成功响应，响应中含有 ETag。用户代理将生成如下 NEL 报告：

   示例 8

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.1",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {},
       "response_headers": {
         "ETag": ["01234abcd"]
       },
       "status_code": 200,
       "elapsed_time": 1392,
       "phase": "application",
       "type": "ok"
     }
   }

2. 之后用户代理又发送一次 请求，本地仍有原始资源副本，并在 If-None-Match 请求头中添加其版本。服务器检查该版本仍然有效，并返回 304 响应，表示缓存依然有效。用户代理将生成如下报告：

   示例 9

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.1",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {
         "If-None-Match": ["01234abcd"]
       },
       "response_headers": {
         "ETag": ["01234abcd"]
       },
       "status_code": 304,
       "elapsed_time": 45,
       "phase": "application",
       "type": "ok"
     }
   }

3. 晚些时候，用户代理再次向 example.com 发送 请求，缓存依然，与前例一样带了 If-None-Match，但服务器此时检测到有新版本，生成并下发新内容及新的 ETag，用户代理生成如下报告：

   示例 10

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.1",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {
         "If-None-Match": ["01234abcd"]
       },
       "response_headers": {
         "ETag": ["56789ef01"]
       },
       "status_code": 200,
       "elapsed_time": 935,
       "phase": "application",
       "type": "ok"
     }
   }

对于 origin 的 域名解析为多个 IP 地址的情况，NEL 有时会“降级”错误报告，仅保留更少的出错信息，因为用户代理无法确认 origin 的拥有者和实际 服务器的拥有者一致。

例如，假设 example.com 由三个不同 IP 地址的 服务器 负责，服务端将 DNS 解析为 192.0.2.1、192.0.2.2、192.0.2.3，并依靠用户代理对其请求进行负载均衡。服务所有者会下发如下 NEL 策略：

> GET / HTTP/1.1
> Host: example.com

< HTTP/1.1 200 OK
< ...
< Report-To: {"group": "network-errors", "max_age": 2592000,
              "endpoints": [{"url": "https://example.com/upload-reports"}]}
< NEL: {"report_to": "network-errors", "max_age": 2592000,
        "success_fraction": 1.0, "failure_fraction": 1.0}

基于上述，考虑如下事件序列：

1. 用户代理向 192.0.2.1 发送 请求，收到 成功响应。响应中也包含上述 NEL 策略，用户代理将策略的 接收 IP 地址 设为 192.0.2.1。由于接收 IP 地址与服务器 IP 地址匹配（成功请求必然如此），生成如下 NEL 报告：

   示例 12

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.1",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {},
       "response_headers": {},
       "status_code": 200,
       "elapsed_time": 57,
       "phase": "application",
       "type": "ok"
     }
   }

2. 用户代理再向 192.0.2.2 发送请求收到成功响应，此响应同样包含 NEL 策略，用户代理将策略的 接收 IP 地址 更新为 192.0.2.2，由于匹配，生成如下报告：

   示例 13

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.2",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {},
       "response_headers": {},
       "status_code": 200,
       "elapsed_time": 34,
       "phase": "application",
       "type": "ok"
     }
   }

3. 用户代理再尝试向 192.0.2.3 发送请求，但无法建立连接。此时策略仍在 策略缓存中，理想状况下用户代理会生成 about 失败 网络请求 的 tcp.timed_out 报告。但实际上由于策略中的“接收 IP 地址” (192.0.2.2) 与本次请求实际的服务器 IP 不符，用户代理无法确认 192.0.2.3 是否归属于 example.com 拥有者，因此必须降级为 dns.address_changed：

   示例 14

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.3",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {},
       "response_headers": {},
       "status_code": 0,
       "elapsed_time": 0,
       "phase": "dns",
       "type": "dns.address_changed"
     }
   }

4. 用户代理再试图向 192.0.2.1 发送新请求，但依然无法建立连接。尽管用户代理曾经从 192.0.2.1 获得过 NEL 策略，但策略记录的“接收 IP 地址”仅保留最近一次获取时的（这里为 192.0.2.2），因此依然需要降级为 dns.address_changed：

   示例 15

   {
     "age": 0,
     "type": "network-error",
     "url": "https://example.com/",
     "body": {
       "sampling_fraction": 1.0,
       "server_ip": "192.0.2.1",
       "protocol": "http/1.1",
       "method": "GET",
       "request_headers": {},
       "response_headers": {},
       "status_code": 0,
       "elapsed_time": 0,
       "phase": "dns",
       "type": "dns.address_changed"
     }
   }

用户发起的导航请求（如点击链接、地址栏直接输入，由用户操作触发的脚本导航等），可能因多种连接性问题而失败：如 DNS 失败、TCP 错误、TLS 协议违规等。这些错误可能由网络配置错误、临时路由问题、服务器宕机、恶意软件或针对用户的攻击等原因造成。

在这种情况下，目标主机往往无法意识到导航失败，因为其根本看不到该请求进入自己的基础设施，也无法调查问题原因。为了解决这个问题，主机可以向用户代理注册一个NEL 策略，指定这些失败报告应投递到哪里，以便进行后续分析。

一个典型的应用需要几十个资源，这些资源通常通过 HTML、CSS 或 JavaScript 进行拉取。应用本身可以通过 onerror 回调等方式观察到部分失败，但无法获知导致失败的详细网络错误原因，例如 DNS 故障、TCP 错误、TLS 协议错误等。

为解决这一问题，应用可以为用于拉取子资源的第一方主机向用户代理注册相关的NEL 策略。这样，只要策略存在且遇到某一已注册origin资源的网络错误时，用户代理就会报告详细的网络错误，帮助开发者排查故障。

当资源被第三方嵌入时，资源提供者通常无法埋点或观察到失败。例如 example.com 在站点中嵌入了 widget.com/thing.js 资源，而访问 example.com 的用户如果因网络错误拉取该资源失败，widget.com 主机既不知晓也无法检测此失败。

为解决该问题，widget.com 可以为自身主机注册 NEL 策略。这样，只要策略生效，无论资源是从第一方还是第三方 origin 拉取，只要遇到网络错误——只要目标origin注册了NEL 策略，用户代理就会报告网络错误并使服务商能够排查问题。

Header field name

NEL

Applicable protocol

http

Status

standard

Author/Change controller

W3C

Specification document

本规范（见NEL 响应头）