Is it possible to configure a service, which does active healthchecks on port 80, but routes proxy requests to port 443?
In my targets, I have port 80 configured because the healthchecks must be over HTTP - but I’d like the actual API traffic to be over TLS 443, so I have port 443 specified in the Service. However, according to logs, proxy requests still route exclusively to port 80.
Is it possible to change that?
Looking at the code seems the target port will always override the service resource port even if set. @thibaultcha was this intentional? In the event teams may want an http healthcheck vs an https proxy. Would a PR to next branch be allowed using ngx.ctx.service.port if set as an override be sensible as opposed to target port for health-check? Ofc we intend to mostly use all https healthchecking and proxy when TLS works on Kong health checks. But even after that TLS feature comes in allowing flexibility is probably ideal.
Currently testing a small change to balancer.lua to determine if it works like that
@thibaultcha was this intentional?
As far as I know, yes, and it is the behaviour we are looking for. I am not the author of this part of the code, @Tieske is. Upstreams/Targets override DNS resolution, including that of SRV records which contain ports, especially useful in container orchestration and service discovery environments. Since Upstreams/Targets allow for a manual override of upstream IPs/ports, they must take precedence over a port defined on the Service entity.
In the event teams may want an http healthcheck vs an https proxy.
I am having a hard time understanding why someone would trust a healthcheck if it isn’t checking the correct port. Especially in this direction (i.e. healthcheck HTTP vs proxy HTTPs). Is this just a workaround for the lack of HTTPs healthcheck support?
Would a PR to next branch be allowed using ngx.ctx.service.port if set as an override be sensible as opposed to target port for health-check?
That sounds… Somewhat brittle but also like a considerable breaking change? I doubt so, unless I misunderstood the purpose of the patch.
Hit the nail on the head there mate 
(workaround for now but still like the idea too of diff ports between proxying or healthchecking if desired). I think in industry its common to have healthchecks over http to a service that just returns 200 letting people know its boogying vs private data to secure on the actual proxy transaction(over https). Just thought to loop you in on this to consider the possibility adding additional flexibility around the setting of the port. We are verifying overwriting the port works using the ctx locally right now just for fun, seems like it may have actually worked at first glance.