The problem is probably that your port range is still too narrow. In case of TCP it is sufficient to bind a listener to one specific port to be able to handle many clients. TCP is reliable. That means a message sent from one side will arrive the opposite side. In case of UDP that’s not guaranteed. There is no such listener. A message is being sent directly to a specific port. A UDP session is defined by IP address/port combo and a timeout.
If a response arrives before the timeout is reached, the session is being closed and the port gets available for further communication. If a response doesn’t arrive, the port stays busy for the period defined by the timeout. If you get such a situation on say 5 ports at the same time, you run out of ports available for communication.
As was discussed in Remote returned status code 400, ICE usually needs a bit more ports than the amount of P2P connections you want to have. What that commit does is it adds another STUN server, thus (roughly?) doubling the amount of STUN binding requests your proxy does.
So I suspect what’s happening is you run out of ports and stop being able to make STUN requests, making the amount of candidates you send in the answer 0, and the broker currently rejects answers with 0 ICE candidates.
To “revert” that commit, try adding -stun=stun:stun.l.google.com:19302 to only use one STUN server again, or try increasing the ephemeral ports range again.
And I could sort of reproduce it with the same CLI arguments on my VPS, where at some point it stopped including server-reflexive candidates in the answer and only sending host candidates.
