feat(consul): support https consul server addresses

[nic-6443]

Description

This lets consul discovery talk to Consul servers over https. Today format_consul_params only accepts http:// addresses. An https:// server fails registry startup with only support consul http schema address, and since that runs inside the init_worker / start path, discovery for it just never comes up.

The scheme is now decided per server address, so one servers list can mix http and https. For https entries the client hands TLS to lua-resty-consul (ssl = true, sni_host = <host>, ssl_verify = true) at both places that build a client: the watch path (get_opts) and fetch_services_from_server. The certificate is checked against the host in the address. Trust comes from lua_ssl_trusted_certificate, i.e. apisix.ssl.ssl_trusted_certificate, the same way the nacos https support works. An https address without a port uses 443 (parse_uri's default). I didn't add schema fields for skip-verify or a per-registry CA.

Any other scheme is still rejected, with a message that now mentions https. One small side fix: http.parse_uri returns nil for a scheme other than http/https, so something like tcp://... used to crash in unpack(nil) instead of reaching that message. It now returns the error properly.

t/discovery/consul-tls.t puts a TLS server block (test cert signed by apisix.crt) in front of the CI consul on 8500. It checks that a route with discovery_type: consul resolves through an https://localhost:18501 server in both long and short connect mode, and it checks the per-address scheme handling and the rejection of other schemes. The docs for consul discovery and the config.yaml.example comment are updated too.

Which issue(s) this PR fixes:

N/A

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)

[Copilot]

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Copilot review overview

3 open findings

• ssl_verify and sni_host are being set unconditionally even when the server is plain HTTP (`ssl… · New
• http.parse_uri can return nil, err not only for non-http(s) schemes but also for malformed… · New
• Same as get_opts: ssl_verify/sni_host are set even for http:// servers. Keeping TLS-only… · New

What changed in this PR

Adds HTTPS support to Consul service discovery so APISIX can communicate with Consul agents over TLS, including mixed http/https server lists, with docs and tests to validate behavior.

Changes:

• Allow Consul server addresses using https:// (mixed with http://) and pass TLS options to the Consul client.
• Improve handling of unsupported schemes so they return a proper error instead of crashing.
• Add an E2E-style TLS test and update documentation/examples to explain CA trust configuration.

File	Description
apisix/​discovery/​consul/​client.lua	Adds per-server scheme parsing and wires TLS/SNI/verify options into resty-consul usage.
t/​discovery/​consul-tls.t	New test coverage validating HTTPS Consul discovery and mixed-scheme parsing/error cases.
docs/​en/​latest/​discovery/​consul.md	Documents HTTPS scheme support and how to configure the trusted CA bundle.
conf/​config.yaml.example	Updates comment to indicate Consul servers may be http or https.

🧠 Review effort: Lite

---

Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.