Kirill wrote:
now everything goes to :8200. I feel I'm getting closer.I use this way: table <vaultwarden> { 127.0.0.1 retry 5 } ... table <fallback> { 127.0.0.1 retry 5 } http protocol https { tls keypair XXX.com pass request forward to <fallback> ... tls keypair vaultwarden.XXX.com pass request header "Host" \ value "vaultwarden.XXX.com" forward to <vaultwarden> } relay https { listen on egress port 443 tls protocol https forward to <vaultwarden> port 8000 \ check http "/" code 200 ... forward to <fallback> port 80 \ check http "/" code 200 }
Ahhh, so fallback with tls and multiple host names is possible! Or am I reading too much into this? OK, so here is my understanding of how relayd works with relays: - every destination needs a table, even if to the same localhost - multiple destinations need multiple tables, one for one, even if going to localhost. - tables define targets for relay, but they also carry health- checking information (definitions and status). Table lookups use health-check results. - protocols process TLS (including multiple TLS hosts) together with parameters. "Protocols ...define settings and rules for relays" says the doc. - the relay clause allows multiple forwardings but the document says "subsequent entries will be used as the backup table if all hosts in the previous table are down." Which is unclear to me: is the last in the list used, or are they searched sequentially? In Kirill's example, does <fallback> get traffic only if <vaultwarden> and any other tables are all simultaneously down? - reading the doc closely does result in a state of simultaneous awe and mystery. There is no fix for that. J
