{
  "test_id": "T16",
  "verdict": "pass",
  "observed": "connectionPool.tcp.idleTimeout(4s)와 tcpKeepalive(time=1s/interval=2s/probes=10, 원본 스펙은 20s/3s/2s/10이었으나 공유 mock 백엔드의 Node.js 기본 keepAliveTimeout(~5-6s)에 막혀 4s/1s/1s/10으로 축소 조정)를 함께 설정한 뒤 데이터 없는 유휴 연결을 nc로 10초간 유지한 결과, upstream_cx_idle_timeout 카운터가 0에서 1로 증가했다. 동시에 upstream_cx_destroy_local이 0에서 1로 늘고 upstream_cx_length_ms 히스토그램에 idleTimeout=4s와 거의 일치하는 ~4050ms 값이 새로 잡혀, 해당 연결이 원격(백엔드)이 아닌 Envoy 자신의 유휴 타이머에 의해 로컬에서 종료되었음이 확인됐다. /config_dump로 idleTimeout은 common_http_protocol_options.idle_timeout(L7)에, tcpKeepalive는 upstream_connection_options.tcp_keepalive(L4 SO_KEEPALIVE)에 각각 독립적으로 매핑됨을 확인했으며, 최초 GET 요청은 200 OK로 정상 응답해 연결이 idleTimeout 발동 직전까지 정상 동작했음을 보여준다.",
  "claims": [
    {
      "doc": "blog:egress_tcp-keepalive-fields",
      "cid": "C12",
      "empirical": "supports-claim",
      "note": "tcpKeepalive가 정상 동작(연결 성공/응답 정상)해도 idleTimeout 카운터가 예정대로 증가해, keepalive가 idleTimeout을 리셋하지 못함을 확인"
    },
    {
      "doc": "blog:egress_tcp-tuning",
      "cid": "C6",
      "empirical": "supports-claim",
      "note": "idleTimeout이 설정된 시간(~4s)에 정확히 연결을 끊음을 upstream_cx_length_ms 히스토그램(~4050ms)과 upstream_cx_destroy_local 증가로 확인"
    },
    {
      "doc": "blog:egress_tcp-tuning",
      "cid": "C7",
      "empirical": "supports-claim",
      "note": "tcpKeepalive와 idleTimeout이 서로 다른 레이어(L4 SO_KEEPALIVE vs L7 idle timer)의 독립 메커니즘임을 config_dump로 실증, keepalive 존재가 idleTimeout 발동을 막지 못함"
    },
    {
      "doc": "gw__guide-egress-tcp-failure-reproduction",
      "cid": "C7",
      "empirical": "supports-claim",
      "note": "동일 실험으로 keepalive 성공적 왕복에도 불구하고 idleTimeout 시점에 연결이 절단되는 재현 절차가 유효함을 확인"
    }
  ]
}
