De modo geral, com MTR (ou WinMTR) você não deve se concentrar muito na perda de pacotes de saltos intermediários, pois isso geralmente é causado por limites no tráfego ICMP destinado a eles mesmos (porque geralmente esse tipo de tráfego requer recursos adicionais de eles). Se você vir uma certa quantidade de perda de pacotes em um salto, seguido por uma perda de 0% no próximo salto, você pode ter certeza de que não é uma perda que afetará seu tráfego (em outras palavras, uma perda real em um específico). hop mostrará a mesma ou mais perda de pacotes em TODOS os próximos saltos até o destino).
Além disso, observe a média de latência para entender o desempenho, mantendo um olho no desvio padrão (se for muito alto, a latência média não faz sentido, mas não tenho certeza se o WinMTR pode mostrá-lo).
Ao analisar sua saída de qualquer maneira, vejo cerca de 2% de perda e uma latência em torno de 160ms até o último salto rastreado, nada que evidencia uma rede inutilizável honestamente.
Infelizmente, o seu MTR não mostra o caminho completo, mas se você tiver o mesmo problema com outros serviços da Internet, poderá rastrear os IPs que respondem como 8.8.8.8.
No entanto, lembre-se de que o MTR não representa o mesmo fluxo que você está usando com o seu serviço; Para testar melhor essa conectividade, você deve configurar um teste "iperf" que use os mesmos soquetes, mas isso não é possível se você não tiver acesso à rede remota. Apenas com o MTR, as informações de largura de banda são perdidas, seu tráfego pode ser moldado / policiado ao longo do caminho de uma maneira diferente em comparação com o tráfego aplicado ao tráfego MTR, e assim por diante.
Mais uma vez, se os seus problemas não estiverem relacionados apenas a esse serviço específico, mas a toda a navegação na Internet, testes como o www.speedtest.net/ poderão dar-lhe excelentes informações.