Андрей

Если Вы отправляете с сервера на клиент информацию, содержащую белый IP, всё должно быть хорошо.

Если Вы отправляете с клиента на сервер информацию, содержащую серый IP, то сетевое устройство, выполняющее в сети клиента NAT (меняющее серые адреса на белые), должно понимать протокол передачи, заменять серые адреса и порты на белые внутри Вашего пакета и открывать соответствующие этим портам дополнительные временные NAT-туннели. Эта технология называется "ip inspect". Если Ваш протокол проприетарный, то вряд ли сетевое оборудование будет уметь его декодировать, чтобы модифицировать передаваемые внутри его IP и порт.

Если Ваш процесс принципиально (среднестатистически) не успевает обрабатывать такой поток - Вам все равно придется сбрасывать эти пакеты (либо это будет происходить в буфере сокета на уровне ОС ( smallvoid.com/article/winnt-winsock-buffer.html ), либо у Вас в приложении (приемом пакета без обработки) - решайте сами).

Если же поток от клиентов неравномерный и Вы не успеваете только в какие-то локальные моменты времени, а среднестатистически быстродействие сервера достаточно, то записывайте все пакеты в свой прикладной (например, циклический) буфер (хоть на несколько мегабайт) - это очень быстрая операция; а потом считывайте процессом-обработчиком. (Если конечно, задержка обработки не сказывается у Вас на целях предметной области).

HTTPS CONNECT + функционал постоянной поддержки соединения со стороны клиента (переподключение при разрыве).
Внутри этого TLS-соединения Вы можете реализовывать любой обмен: хоть запрос-ответ в стиле HTTP, хоть просто обмен данными.
Преимущество - прозрачное прохождение прокси-серверов + шифрование.
Некоторые прокси режут HTTPS CONNECT, если он длится более суток, поэтому клиентское ПО должно уметь его пересоздавать.