feat(nginx): Route hostnames whose TLS is terminated upstream#177
Merged
Conversation
A hostname fronted by an external proxy such as Cloudflare could not reach the deployment behind it. The proxied request arrives with that hostname as its Host, which matched no configured server name and fell to the unknown-domain catch-all. Adding it as an alias did route it, but aliases are also submitted for certificate issuance, which fails because the hostname's DNS points at the external proxy rather than at FlatRun, so there was no way to accept a hostname for routing while its certificate is handled elsewhere. A hostname can now be marked routing-only. It routes to the deployment and shares the primary domain's certificate over the external proxy's SNI, and it is kept out of certificate issuance and renewal so a request it cannot satisfy is never made. Its traffic counts as a known domain rather than unknown.
Code Review SummaryThe PR introduces a feature to route hostnames whose TLS is terminated by an upstream proxy (e.g., Cloudflare), ensuring they don't trigger ACME certificate issuance. While the SSL and model logic are correct, there is a critical logic error in the Nginx configuration generation that needs to be addressed. 🚀 Key Improvements
💡 Minor Suggestions
🚨 Critical Issues
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A hostname fronted by an external proxy such as Cloudflare could not reach the deployment behind it. The proxied request arrives with that hostname as its Host, which matched no configured server name and fell to the unknown-domain catch-all. Adding it as an alias did route it, but aliases are also submitted for certificate issuance, which fails because the hostname's DNS points at the external proxy rather than at FlatRun. There was no way to accept a hostname for routing while its certificate is handled elsewhere. Closes #166.
A hostname can now be marked routing-only. It routes to the deployment and shares the primary domain's certificate over the external proxy's SNI, and it is kept out of certificate issuance and renewal so a request it cannot satisfy is never made. Its traffic counts as a known domain rather than unknown.
The marker is a per-domain list kept separate from aliases, because the routing-only hostname must live in the same server block as its parent domain to borrow that certificate via SNI. Certificate gathering only reads the alias list, so exclusion from issuance and renewal follows without touching the SSL path.
Scope note: this covers the externally-terminated-TLS case where the proxy reaches the origin over HTTPS with the primary domain's SNI. A direct plain-HTTP request to the origin for a routing-only host still hits the existing port-80 redirect to HTTPS; splitting the redirect block for these hosts is a possible follow-up.
UI counterpart: flatrun/ui#84.