{
  "test_id": "T56",
  "verdict": "fail",
  "observed": "run 1을 막았던 환경 문제 두 가지는 이번에 모두 해소됐다. (1) net.ipv4.ip_local_port_range를 pod.spec.securityContext.sysctls로(런타임 sysctl -w 대신) 설정하니 curl/istio-proxy 두 컨테이너 모두에서 20개 포트(32768-32787)로 정확히 좁혀진 것을 /proc/sys 읽기로 확인했다 — 이는 파드 전체가 공유하는 netns에 CRI가 컨테이너 시작 전에 적용하므로 컨테이너 capability와 무관하게 성공한다. (2) echo 서비스를 짧은 이름(http://echo.<ns>/)으로 호출하니 access log의 cluster 필드가 PassthroughCluster가 아니라 정확히 outbound|80||echo.<ns>.svc.cluster.local로 라우팅됐다(istiod 레지스트리 이름이 실제 클러스터 DNS 도메인인 homelab.local과 무관하게 cluster.local로 고정되기 때문에, vhost 매칭에는 짧은 이름을 써야 한다는 교정 규칙이 그대로 확인됨). 다만 스펙이 지시한 순차(sequential) 200회 반복 루프는 실패를 전혀 만들어내지 못했다(200/200 성공, 1.5초 만에 완료) — 이 노드의 net.ipv4.tcp_tw_reuse=2(커널 기본값) 때문에 동일 목적지로의 새 connect()가 TIME_WAIT 소켓을 즉시 재사용할 수 있어, 단일 스레드로 순차 호출하는 한 20개 포트로는 결코 고갈되지 않는다. 이 방법론적 한계를 확인하기 위해 60회 동시(concurrent) 요청으로 추가 부하를 걸었더니 실제로 60건 중 12건이 curl exit=7(connect 실패)로 떨어졌다 — 포트+TIME_WAIT 고갈이라는 전제 현상 자체는 실재로 재현됐다. 그러나 이 12건의 실패는 Envoy(istio-proxy)의 access log에 단 한 줄도 남지 않았다(관측 구간 총 260회 요청 중 access log는 정확히 248줄 = 260-12, 실패 건수와 정확히 일치). /clusters 엔드포인트(스탯 필터링을 받지 않는 대안 채널로 사용 — /stats 평문 엔드포인트는 이 클러스터의 기본 stats-inclusion matcher 때문에 istiod용 xds-grpc 클러스터를 제외한 어떤 outbound 클러스터 카운터도 노출하지 않음이 확인됨)로 본 outbound|80||echo 클러스터의 cx_connect_fail은 부하 전후 모두 0으로 변화가 없었고(cx_total만 2->17로 소폭 증가, keep-alive 커넥션 풀 재사용으로 설명됨), access log 전체 관측 구간에서 UF를 포함한 어떤 비-기본 response flag도 전혀 나타나지 않았다. 원인은 명확하다: 파드 단위(컨테이너 단위가 아님) sysctl 좁히기는 클라이언트->사이드카(루프백, 127.0.0.1:15001) 구간과 사이드카->업스트림(echo) 구간이 동일한 20개 포트 풀을 공유하게 만들며, 실패는 사이드카가 업스트림 연결을 시도하기도 전에 클라이언트 자신의 connect()가 실패하는 형태로 나타난다. 즉 Envoy는 이 실패 요청을 아예 수신조차 못 하므로 UF도 upstream_cx_connect_fail도 결코 발생할 수 없는 구조다. pass_criteria의 세 조건 중 TIME_WAIT 소켓 수(14~25, 20에 근접)는 대략 부합했으나, 핵심 두 조건(upstream_cx_connect_fail 증가, access log UF 발생)은 재시도 후에도 명확히 불성립했다.",
  "claims": [
    {
      "doc": "gw__guide-egress-tcp-failure-reproduction",
      "cid": "C4",
      "empirical": "refutes-claim",
      "note": "connect 실패 자체는 실재로 재현했다(동시 60개 요청 중 12개가 curl exit=7로 확인). 그러나 사이드카 모드에서 pod-wide(컨테이너가 아닌 파드 전체 netns) 포트 범위 좁히기를 쓰면 클라이언트->사이드카 루프백 구간이 사이드카->업스트림 구간과 동일한 포트 풀을 공유하기 때문에, 실패가 Envoy의 프록시 로직에 도달하기 전 클라이언트 자신의 connect() 단계에서 일어난다. 그 결과 Envoy의 access log에는 해당 요청 자체가 기록되지 않고(UF 포함 어떤 response flag도 없음), 업스트림 클러스터의 cx_connect_fail 카운터도 전혀 증가하지 않는다(부하 전후 0으로 동일, cx_total만 keep-alive 재사용으로 소폭 증가). 즉 'connect 실패 시 UF/upstream_cx_connect_fail이 남는다'는 클레임은 이 재현 방법론(파드 단위 sysctl 좁히기) 하에서는 성립하지 않는다 — 실패는 실재하지만 Envoy 관측 지표에는 완전히 비가시적이다. 추가로 /stats 평문 엔드포인트는 이 클러스터 기본 설정상 outbound 클러스터의 세부 커넥션 카운터를 애초에 노출하지 않아(istiod 자체 통제용 xds-grpc 클러스터만 노출), 스펙이 지시한 grep 대상 자체가 이 클러스터에서는 구조적으로 빈 결과만 낼 수 있다는 점도 별도로 확인했다(동일 카운터를 노출하는 /clusters로 대체 검증)."
    }
  ]
}