{
  "test_id": "T08",
  "verdict": "pass",
  "observed": "portconflict-gw의 8443 리스너에서 filterChains 길이가 2로 확인되었고, filterChainMatch의 serverNames가 각각 echo.istio-vt-t08.svc.homelab.local(ISTIO_MUTUAL, requireClientCertificate=true)과 mock.istio-verify-ext.svc.homelab.local(PASSTHROUGH, transportSocket 없음)로 정확히 분리되어 있었다. istiod 로그에는 conflict/duplicate/filter_chain_not_found류 메시지가 전혀 없었고, 게이트웨이 access log에서도 두 curl 연결의 SNI가 각자의 체인으로 정확히 라우팅되는 것을 확인했다(교차/충돌 없음). via_A_passthrough는 EDS 수렴 후 재시도에서 200으로 종단간 성공했고, via_B_mutual은 지속적으로 실패(000)했는데, istioctl analyze의 IST0101(Referenced host not found: echo.istio-vt-t08.svc.homelab.local)과 클러스터 목록 조사로 원인을 특정했다 — VirtualService route-b의 destination.host가 실제 클러스터 도메인(homelab.local)을 썼지만 Istio 내부 서비스 레지스트리는 여전히 cluster.local 접미사로 클러스터를 생성하여 EDS 클러스터를 찾지 못한 것(NC)이었고, 이를 격리 테스트로 patch하여 cluster.local로 바꾸자 클러스터 조회는 성공했으며 남은 실패는 curl이 클라이언트 인증서를 제시하지 않아 ISTIO_MUTUAL의 requireClientCertificate 요건에서 정상적으로 거부된 것으로 확인되어, 머지 충돌과는 무관함이 입증되었다.",
  "claims": [
    {
      "doc": "gw__report-2026-06-08_egress-mtls",
      "cid": "C6",
      "empirical": "refutes-claim",
      "note": "동일 포트 PASSTHROUGH+ISTIO_MUTUAL이 SNI 기반 filter chain 2개로 정상 공존, conflict 로그 없음 -> '같은 포트=반드시 드롭' 주장 재현 안 됨(문서 자체도 doc-unverifiable이었는데 그 회의적 추정이 맞았음)."
    },
    {
      "doc": "gw__src-egress-https-over-mtls",
      "cid": "C6",
      "empirical": "refutes-claim",
      "note": "문서는 이 시나리오를 confirmed로 단정했으나, Istio 1.30 실측에서는 filterChains=2로 SNI 정상 분리, PASSTHROUGH 경로 200 종단간 성공, filter_chain_not_found 없음 -> '한쪽 서버 드롭' 주장 반박됨."
    }
  ]
}