Execute o comando curl na máquina MacOSX, mas não redirecione a saída, deixe-a transmitir para a janela do seu shell. Preste atenção para ver se parece haver algum buffer envolvido, ou seja, você obtém a saída desde o início, um pouco de cada vez, ou você não obtém nada por 5 minutos e depois uma enxurrada de dados de uma vez?
Execute o comando curl novamente em uma máquina em que ele expira e compare o comportamento. Se a sua saída estiver sendo armazenada em buffer por algum processo em segundo plano no servidor de API, você poderá não obter resultados até que conclua sua consulta. Algo entre seu aplicativo cliente, o sistema operacional do seu cliente, o sistema operacional do servidor, a API REST do servidor e o SSL entre eles provavelmente tem um valor de tempo limite diferente de zero e, se esse cronômetro não vir nenhum fluxo de dados por cinco minutos, pode fechar sua conexão sem dizer muito sobre o motivo. Eu vejo isso acontecer muito em serviços baseados em HTTP. Em perl, costumo colocar um $|=1; no topo do código para desativar o buffer de saída no lado do servidor.
Também é possível que um dispositivo de terceiros, como um Cisco ASA, possa ter regras de tempo limite e problemas de acionamento. Eu tenho esse problema com backups AMANDA que estão tentando ler de um cliente no lado externo de um ASA. Se o cliente demorar muito para retornar suas estimativas de tamanho através do ASA de volta ao servidor AMANDA, o ASA descartará sua regra de NAT dinâmica e o backup falhará. Vale a pena investigar essa sugestão se o MacOSX que funciona não tiver um firewall entre ele e o servidor da API, mas os que falharem têm um.
Não me surpreenderia se o MacOSX tivesse um valor de tempo limite definido em algum lugar como 0 (espere para sempre), onde o Linux usa como padrão algo com um limite de 60 ou 90 segundos.