caddy-l4

Summary I have an forgejo service running on my homelab behind caddy reversed proxy along with an mcp server in subpath , I want to configure SSH-over-TLS, while keeping subpath reverse proxy and port settings, I've modified Caddyfile according to documents, but all i got is error, Is there any flaws in my configuration or am I missing something? Step to reproduce 1. Build caddy with caddy-l4 module using xcaddy. 2. Run caddy server using the following Caddyfile: 3. Use following command to connect to ssh server over https port: Expected Behavior SSH client should connect to server and start asking whether or not to remember fingerprint Actual Behavior SSH client returns error, while https service is still accessible

This PR supersedes #420 and closes #439. The original PR didn't let any changes to be made by the maintainers, and the author didn't respond to pings. So I copied the original commit submitted by @carterbryden co-authored by an LLM (presumably, Copilot) and applied the Copilot's suggestions after it had reviewed the original PR submitted by @apxcarter, then merged into the current branch.

I'm trying to use to route the Syncthing Relay Protocol, which is actually _two_ protocols multiplexed on a single port: "Protocol mode" for control messages: TLS with ALPN . I confirmed this can be handled with a matcher. "Session mode" for relay sessions: a header starting with magic bytes , followed by an arbitrary sequence of bytes. According to the docs, I _should_ be able to match the "session mode" initiation packet with , but that doesn't work. I factored out a minimal (ignoring the TLS "protocol mode", because that works fine): Test it as follows: The matcher succeeds, routing to the handler as expected. However, the matcher never matches, so the connection gets routed to the catchall handler instead. I think the issue is that Go's package assumes bytes to check for a match are valid UTF-8, which means it can't properly match against non-UTF-8 sequences (which are common in application protocol headers). A quick scan of the source code seems to confirm this. I can see a couple paths forward here: 1. Find an alternate regular expressions package that properly supports "binary regex". However, I am not familiar with Go and am not sure if a good candidate exists, especially given that matching is performance sensitive. 2. Write a simpler matcher that only looks for binary substrings in a specific position of the initial packet sent by the client. I envision syntax like , so for my use case, just . It'd be a shame to lose the flexibility of regex, but I suspect many protocols don't actually need it. (It might also be slightly more efficient, though I don't know if that matters in practice.) Personally, (2) seems like the simplest option to resolve the issue I'm facing; however, it doesn't help someone who needs _both_ the flexibility of regex _and_ real byte string matching. (The fact nobody seems to have reported this previously in the couple years the matcher has existed suggests to me that needing both those things at once is uncommon, though. I wouldn't be surprised if binary protocols tend to have a simple, strict magic number like the Syncthing protocol does....)