Tenho uma API que escrevi que usa TCP para transmitir dados bidirecionalmente. Ela funciona perfeitamente bem na minha configuração local. Mas quando mudo para produção, ela nunca atinge o ponto final.
O servidor de produção usa ELB para balancear carga de uma instância EC2 e tudo isso é liderado pelo Cloud Flare.
No começo, eu nem conseguia ver que ele atingiu os logs do NGINX, então fui até o CloudFlare e acertei o endereço IP do EC2 diretamente. Isso fez com que a tentativa aparecesse nos logs de acesso, mas todos eles imediatamente 499 curtiram isso.
[16/set/2024:03:13:50 +0000] "POST /api/user_sync HTTP/1.1" 499 0 "-" "MYAPP/1.0.6 CFNetwork/1494.0.7 Darwin/23.6.0"
499 parece indicar que o cliente abortou a conexão, mas posso ver no meu aplicativo que a conexão com o servidor não é encerrada até que o tempo limite do lado do cliente seja atingido. Mas o 499 aparece instantaneamente nos logs de acesso do NGINX. Então é como se ele o desligasse imediatamente.
Infelizmente, não tenho muita experiência com NGINX, balanceamento de carga ou sites em geral, então qualquer ajuda seria muito apreciada.
Eu encontrei algumas postagens onde outros usuários estavam tendo problemas semelhantes, embora para eles, o 499 acontecesse para cada chamada de API, ou após um longo período de tempo. No entanto, isso acontece TODA VEZ e apenas para este endpoint específico.
Alguém mais que encontrar esta postagem!
Tanto o ELB quanto o NGINX estavam bagunçando as coisas. O ELB espera até que uma certa quantidade de dados tenha sido enviada no fluxo antes de jogá-los fora. Mas isso não funciona para nós porque a carga útil inicial do protocolo é muito pequena (como 100 caracteres).
Então contornamos isso.
Aparentemente, o NGINX não é fã de codificação de transferência em blocos (acho que esse era o problema), então acabamos contornando isso também.
Como essa API não pode ser armazenada em cache, acabamos contornando o varnish também.
Tudo isso envolveu coisas como configurar novos grupos de segurança que encaminhavam para a porta correta quando chamados em uma URL específica que não era nossa URL principal (pense em purchase.ebay.com em vez de www.ebay.com ).
Mais uma vez, me perdoe pela nomenclatura não técnica, pois eu realmente não sou um cara da web rs