Baoyuantop commented on issue #14079: URL: https://github.com/apache/apisix/issues/14079#issuecomment-6406894796
Thanks for the report and the config snippet. This is unlikely to be an APISIX Admin/Control “healthcheck”. With `enable_admin: false` and `enable_control: false`, APISIX does not keep probing those APIs on the local HTTPS port. Upstream active/passive healthchecks are outbound toward upstream nodes; they do not appear as a TLS client connecting to `127.0.0.1:443` on the gateway itself. The log line is from the **inbound** TLS path (`ssl_client_hello_phase`): something inside the container is opening a TLS connection to the local SSL listener (`0.0.0.0:443`) **without a usable SNI** (common when the client uses a bare IP such as `https://127.0.0.1:443`). APISIX then cannot pick a certificate by SNI and logs `failed to find SNI`. Please check what is initiating that local connection, for example: - Kubernetes / OpenShift liveness or readiness probes hitting HTTPS on `127.0.0.1` / the pod IP without a Server Name - A sidecar, agent, or monitoring scrape doing the same Typical mitigations: probe over HTTP instead of HTTPS, send a proper SNI / Host that matches an SSL object, or avoid probing the SSL listen port. If you still believe this comes from APISIX itself, please share a redacted `apisix.yaml` / `config.yaml` and evidence of who opens the local connection (probe YAML, `ss`/`netstat` while the log fires, or a short packet capture of the TLS ClientHello). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
