Rebase to 3.22

[thespad]

---

• I have read the contributing guideline and understand that I have made the correct modifications

---

Description:

Benefits of this PR and context:

How Has This Been Tested?

Source / References:

[LinuxServer-CI]

I am a bot, here is the pushed image/manifest for this PR:

ghcr.io/linuxserver/lspipepr-swag:4.1.1-pkg-ffd8748d-dev-56ff1d5e193e9981decbf8db1bcf570daed6289c-pr-573

[drizuid]

visual review only, did not test PR

[goupilapps]

I gave it a try and it worked.
I tired it by removing the swag volume and started it.
I created a new nginx server section and added inside:
listen 443 quic;
listen [::]:443 quic;
It failed when I tried to add the reuseport in listen 443 quic reuseport; since the default server config is already using the reuseport

[nemchik]

Tried the new image and updated my confs. I am running behind CF proxy, and had no issues with the changes. Not sure if the CF proxy is masking any problems though, but nothing seems to indicate any issues.

[drizuid]

looks like we should add a header add_header Alt-Svc 'h3=":443"; ma=86400'; and add_header x-quic 'h3' always; as well

https://nginx.org/en/docs/quic.html

potentially put the quic reuseport above the 443 ssl too, esp in light of test from @goupilapps

we will want a note in the readme too, quic uses both tcp and udp

[thespad]

reuseport should be global for the same port/proto combinations.

[thespad]

If we add that header and users aren't exposing 443/UDP it'll probably break things

[nemchik]

If we add that header and users aren't exposing 443/UDP it'll probably break things

Does quic require UDP to function at all? If yes, then wouldn't the changes in this PR basically NOT actually make quic work? I am guessing it doesn't break anything (as long as we don't include the extra header) but it doesn't actually get quic working without the UDP port access?

[drizuid]

Does quic require UDP to function at all?

yes// sorry for short reply, the much larger discussion was in discord if you wanna look later; tl;dr things break in many cases, so it's all going in commented out.

[drizuid]

ok i just finished testing and before i dump shit, ill show the http/3 test result.

i did make some changes

1. added 443/udp on my edge DNAT rule
2. added 443:443/udp to my swag compose
3. changed site-conf/default.conf to appear like

server {
    listen 80 reuseport default_server;
    listen [::]:80 reuseport default_server;

    location / {
        return 301 https://$host$request_uri;
    }
}

# main server block
server {
    listen 443 quic reuseport default_server;
    listen 443 ssl reuseport default_server;
    listen [::]:443 quic reuseport default_server;
    listen [::]:443 ssl reuseport default_server;

4. selected plex as my test as it's not behind cf proxy, modified as such

server {
    listen 443 quic;
    listen 443 ssl;

    #listen 443 ssl;
    #listen [::]:443 ssl;
    http2 on;

5. added quic stuff into nginx.conf http section

    # Increase max number of concurrenty HTTP/3 request streams in a connection
    http3_max_concurrent_streams 1024;
    # Increase the size of the buffer used for reading and writing of the QUIC streams
    http3_stream_buffer_size 1024k;
    # Enable sending in optimized batch mode using segmentation offloading
    quic_gso on;
    # Enable QUIC Address Validation feature
    quic_retry on;

6. added two headers to ssl.conf (because we keep optional headers there by default)

add_header Alt-Svc 'h3=":443";ma=86400,h3-29=":443";ma=86400,h3-27=":443";ma=86400' always;
add_header x-quic 'h3' always;

[drizuid]

further testing and discussion was all internal, but consensus is to leave all quic stuff commented out because it CAN break things. some changes to this PR are forthcoming

some notes, if you enable the header for quic and do not have udp/443 open, all of swag appears to break
if you enable the header and the quic config in default.conf but not in proxy-confs they direct to the default landing page

below is a script i used to update all my confs, create backups, i make no claims this script will work for you and i wont provide support or empathy if you choose to use it. it worked for me.

for file in *.conf; do
    if [[ -f "$file" ]]; then
        # Add QUIC after IPv4 SSL if not already present
        if grep -q "listen 443 ssl;" "$file" && ! grep -q "listen 443 quic;" "$file"; then
            sed -i '/listen 443 ssl;/a\    listen 443 quic;' "$file"
        fi
        
        # Add QUIC after IPv6 SSL if not already present
        if grep -q "listen \[::]:443 ssl;" "$file" && ! grep -q "listen \[::]:443 quic;" "$file"; then
            sed -i '/listen \[::]:443 ssl;/a\    listen [::]:443 quic;' "$file"
        fi
        
        echo "Processed: $file"
    fi
done

changes are required post-testing

[LinuxServer-CI]

I am a bot, here is the pushed image/manifest for this PR:

ghcr.io/linuxserver/lspipepr-swag:4.1.1-pkg-a7c1ed85-dev-6329c946ced48036f980e62d04cc55a9cb40edda-pr-573

[drizuid]

looks good to me based on our discussions and my testing

[LinuxServer-CI]

I am a bot, here is the pushed image/manifest for this PR:

ghcr.io/linuxserver/lspipepr-swag:4.1.1-pkg-a7c1ed85-dev-c20d43ecfab263f1babf4299fdd9bb49672e61b2-pr-573

[LinuxServer-CI]

I am a bot, here is the pushed image/manifest for this PR:

ghcr.io/linuxserver/lspipepr-swag:4.1.1-pkg-a7c1ed85-dev-2784cb2a00cd715cb291d6de2d9b7a0ab55ee4c7-pr-573

[LinuxServer-CI]

I am a bot, here is the pushed image/manifest for this PR:

ghcr.io/linuxserver/lspipepr-swag:4.1.1-pkg-a7c1ed85-dev-a577de23611834b2a466a31a428c9bb4ddee4aae-pr-573

[drizuid]

Nice add with the perf notes

[pentago]

I find that using HTTP3 breaks Authelia (4.39.5) as I can't longer access my services.
Worked fine prior to enabling HTTP/3.

I find this in Authelia continer log:

time="2025-07-19T19:43:30+02:00" level=error msg="Target URL does not appear to have a relevant session cookies configuration" error="unable to retrieve session cookie domain provider: no configured session cookie domain matches the url 'https:///'" method=GET path=/api/authz/auth-request remote_ip=x.x.x.x stack="github.com/authelia/authelia/v4/internal/handlers/handler_authz.go:39  (*Authz).Handler\ngithub.com/authelia/authelia/v4/internal/middlewares/bridge.go:66      handlerMain.(*BridgeBuilder).Build.func1.1\ngithub.com/authelia/authelia/v4/internal/middlewares/headers.go:30     SecurityHeadersBase.func1\ngithub.com/fasthttp/[email protected]/router.go:441                        (*Router).Handler\ngithub.com/authelia/authelia/v4/internal/middlewares/log_request.go:14 handlerMain.LogRequest.func30\ngithub.com/authelia/authelia/v4/internal/middlewares/strip_path.go:23  handlerMain.StripPath.func31.1\ngithub.com/authelia/authelia/v4/internal/middlewares/errors.go:38      RecoverPanic.func1\ngithub.com/valyala/[email protected]/server.go:2455                     (*Server).serveConn\ngithub.com/valyala/[email protected]/workerpool.go:225                  (*workerPool).workerFunc\ngithub.com/valyala/[email protected]/workerpool.go:197                  (*workerPool).getCh.func1\nruntime/asm_amd64.s:1700                                               goexit" target_url="https:///"

Did you guys run into similar while testing?

[drizuid]

I find that using HTTP3 breaks Authelia (4.39.5) as I can't longer access my services. Worked fine prior to enabling HTTP/3.

Did you guys run into similar while testing?

I was able to replicate the issue and have brought it up to the authelia team

we likely need ppl to test authentik and tinyauth as well

[pentago]

I think it's possible to circumvent the issue by some headers magic(Host & X-Original-URL). I was able to get my service subdomain appear in logs but not the entire thing yet.

[thespad]

Going to merge this as QUIC is not enabled by default so isn't going to break existing setups, but we'll keep an eye on the 3rd party auth providers.

[lineumaciel]

I was able to replicate the issue and have brought it up to the authelia team

we likely need ppl to test authentik and tinyauth as well

A similar situation exists with Authentik. This occurs quite randomly and manifests itself in URL truncation during redirection after authorization.

[drizuid]

I was able to replicate the issue and have brought it up to the authelia team
we likely need ppl to test authentik and tinyauth as well

A similar situation exists with Authentik. This occurs quite randomly and manifests itself in URL truncation during redirection after authorization.

authelia team stated they dont even support http2 and havent tested 3 at all. They claimed that traefik doesn't have this issue

thread begins here https://discord.com/channels/707844280412012608/707844280412012612/1396194429899112631

[pentago]

I was under impression that Authelia doesn't care about HTTP protocols as nginx deals with that on a layer above it.

Perhaps we could use 1.1 just for authelia if that matters?

[drizuid]

i havent dug much into it personally, if you are going to dig in, please do and let us know what changes we can make to better support. I appreciate all your help thus far (especially with identifying the issue to begin with)

[dgrzjohn]

I think it's possible to circumvent the issue by some headers magic(Host & X-Original-URL). I was able to get my service subdomain appear in logs but not the entire thing yet.

I was getting the same error, and I think I was able to fix this by changing proxy_set_header X-Original-URL $scheme://$http_host$request_uri; to proxy_set_header X-Original-URL $scheme://$host$request_uri; in proxy.conf.

I don't know if this is correct, but everywhere else in proxy.conf has $host instead of $http_host -- which seems to be returning nothing and passing that empty-host URL to authelia when HTTP3 is enabled.

[dgrzjohn]

I was able to replicate the issue and have brought it up to the authelia team
we likely need ppl to test authentik and tinyauth as well

A similar situation exists with Authentik. This occurs quite randomly and manifests itself in URL truncation during redirection after authorization.

authelia team stated they dont even support http2 and havent tested 3 at all. They claimed that traefik doesn't have this issue

thread begins here https://discord.com/channels/707844280412012608/707844280412012612/1396194429899112631

Further searching led to this previous discussion from authelia on the topic of missing http_host with HTTP3 enabled, where my suggestion above is discouraged:

The HTTP/3 protocol does not use the Host header and instead uses the :authority pseudo-header to identify the host name which causes the $http_host variable to be empty and then the following commands return invalid results:

$host previously defaulted to the server_name when absent from the request, this is not very desirable as it has introduced several bugs in the past. We would have to do some testing with alternative server names like server_name auth.*; etc to recommend it as part of the changes, and due to the really difficult to diagnose bugs and the rampant use of unsupported old versions which often have 9.0+ CVE's we may also have to introduce a minimum supported version for this, which I'm fine with.

authelia/authelia#7146

[pentago]

A thing came to my mind, what if all proxy confs had quic but just authelia had ssl listener?

[drizuid]

A thing came to my mind, what if all proxy confs had quic but just authelia had ssl listener?

give it a shot and see, then let us know!

[pentago]

Just made a test where I used:

default.conf listener

listen 443 ssl default_server;
listen 443 quic reuseport default_server;

authelia.subdomain.conf listener

listen 443 ssl;

all other listeners

listen 443 quic;

And also did find/replace $http_host to $host on all config files.

This made things work on most of my services:

Caveat of this is that I noticed some WebSocket issues on sonarr/radarr/emby/thelounge (most likely some other using websockets too):

[pentago]

I found that actually using both quic+ssl listeners helped somewhat but not entirely for all apps:

listen 443 quic;
listen 443 ssl;