Skip cloudflare when being on same local network as origin

I searched for topics and only found this.

I want to use very same thing as stated in this topic, skip getting cloud-flared when I’m on same internal network as origin pull.

Can this be done via caddyfile today?

Not via Caddyfile, no.

The problem is the way the Caddyfile is designed, connection policies are generated based on the site address, with server_name matchers being the site address/domain.

There’s no way to define two connection policies for one site block because of this, for now, so there’s no way to define a remote_ip connection policy matcher in the current config structure.

I’d love to add Caddyfile support for this, but I don’t really see a way to do it right now. Maybe I haven’t thought of a creative enough solution for it yet.

You’ll need to adapt your Caddyfile to JSON (with the caddy adapt command) and adjust your JSON config to do what you need. If you figure out the adjustment you need to do, you could craft a jq command to apply that change to the adapted output so you can keep your Caddyfile but just mutate the adapted JSON with a command. Something like caddy adapt --config Caddyfile | jq '<do some manipulation>' > caddy.json then run from that JSON config.

Okay, I will be crossing fingers at some point that you or any other skilled dev can make this happen via CaddyFile, I’m familiar with json, but I want to keep it all in caddyfile I like the style, really simple :slight_smile:

Another quick asking and maybe another possible way to bypass this in a temporary way until solution comes to caddyfile.

What I’m trying to do is actually to use the load balancer and keepalive_idle_conns_per_host X for lan and wan on same origins, is it possible in anyway to share the lb_policy with load balancer between to sub domains then, so they know when its full of request and use lb_policy least_conn

i.e

Having
wan.domain .com
lan.domain .com

If not, would this be something that could be considered being a feature request to have something share transport keepalive_idle_conns_per_host and lb_policy between multiple domins that will go into very same origin?

I’m not sure I fully understand; are you looking for unhealthy_request_count? I.e. limiting maximum number of active requests to a backend?

So each unit has a limit of 4 max upstreams connections because of 4 tuners pr unit.

So when I go to one of the units on local side via caddy on a secondary sub domain - without cloudflare and just directly on lan side, then when I’m reaching the very same unit from primary sub domain with cloudflare, the 2 sub domains wont be synced of how many clients being hooked up on the same device, which will result in the unit being full when reaching 4 or more and that will cause errors since caddy wont know that the unit is full and collide?

Do I understand this correct unhealthy_request_count 4 is the MAX active connection to upstream unit, if yes even then, the secondary subdomain would not know when its down?

Yeah, so that’s the maximum number of requests (not connections) active for the upstream, and that’s a global count no matter how the upstream is being accessed. Does that help?

Great so unhealthy_request_count is global but I’m sure what I’m looking for is connection and not requests? but then it will work together with load balancing on both sub domains and just jump onto next unit when down/full?

Unfortunately I don’t know a simple way to count connections since connections are pooled in the Go standard library for performance reasons. It may be possible to dive down into that layer but I’m sure it won’t be too simple.

If I understand your question correctly: yes. If a backend has the maximum number of requests active to it, then the backend is considered down and the load balancer will choose the next one.

Personally I find requests a more useful count than connections anyway, since requests represent actual work the server is doing, whereas connections are just pipes.

Thanks!

I don’t know what else to say, you guys are always fast and really helpful no wonder this is taking over recommendations from other software :slight_smile:

I will wait for a possible solution coming to caddyfile hopefully not so long out in the future :slight_smile:

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.