Running nginx-quic in a real environment

Sergey Kandaurov pluknet at
Tue Sep 27 12:05:54 UTC 2022

> On 27 Sep 2022, at 14:11, João Sousa Andrade <joao.andrade at> wrote:
> Thank you for the clarification Sergey. 
> We have been running http3 in production for the past couple of weeks. There's something we have noticed which I'm not entirely sure as to what is causing it.
> We have been getting lots of errors of the form: "[error] 34#34: *338736 quic no available client ids for new path while handling decrypted packet, client: $IP, server:". I tried looking through the code to little avail. I'm wondering what's causing these errors. Is it something which could be tweaked through configuration?

This happens when QUIC connection continues over a new network path,
known as QUIC connection migration, which should by done by switching
to a new connection ID, but the client didn't previously supply enough
Connection ID to chose from.  Normally both peers maintain a set of
unused Connection IDs, which may be needed not only for migration,
but also due to NAT rebinding.  Assuming that peers that initiate
connection migration maintain enough connection IDs, a likely reason
of the network path change failure as seen in the above error can be
due to NAT rebinding with the client implementation that doesn't a notion
of connection migration so it didn't sent NEW_CONNECTION_ID frames.
In the case of NAT rebinding the server should send probing frames
over a new network path using next available client Connection ID,
but there were no any, as seen in the above error.
Hope that helps.

Sergey Kandaurov

More information about the nginx mailing list