Da escolha do servidor e da região à segurança básica, instalação do proxy, autenticação e portas, configuração do cliente, validação e sequência de diagnóstico quando a conexão falha.
Escolha o servidor e a região
Um proxy por si só consome muito pouca CPU e memória, portanto esses recursos não são o principal critério ao escolher a configuração.
Não é necessário começar com um plano potente. Pacotes como servidores de aplicações leves, com largura de banda fixa e franquia mensal de tráfego, normalmente bastam para um proxy de uso próprio com uma ou poucas contas e têm custo baixo. Só vale considerar instâncias de uso geral com recursos configuráveis separadamente quando forem necessárias várias instâncias ou houver requisitos específicos de largura de banda.
A região merece mais atenção do que a configuração, porque o IP de saída pertence ao local onde o nó está implantado. A lógica é simples: coloque o nó no mercado em que a conta vai operar. Muita gente escolhe pela velocidade de acesso. Um nó em Hong Kong pode ser rápido a partir da China continental, mas se o perfil da conta disser Estados Unidos e a saída estiver na Ásia, essa inconsistência pesa mais do que a velocidade. Velocidade é secundária; consistência vem primeiro.
Estime a largura de banda pelo uso real. Para consultar painéis e fazer administração diária, pouca largura de banda costuma bastar; operações com imagens e vídeos exigem mais; e quanto mais contas estiverem online ao mesmo tempo, maior será a necessidade. Em caso de dúvida, comece pelo menor plano, observe o consumo por um mês e ajuste depois.
Conclua estas etapas após ligar o servidor
Escolha uma imagem Linux. Essas distribuições normalmente já incluem SSH, sem necessidade de configurar outro serviço remoto. Na contratação, definir uma senha personalizada em vez de usar um arquivo de chave pode economizar uma etapa de conversão mais tarde ao configurar o proxy.
Assim que receber o servidor, anote quatro informações: IP público, nome de usuário (root por padrão no Linux), senha e porta SSH (22 por padrão). São esses dados que serão preenchidos no cliente.
Depois faça a configuração básica de segurança. Alterar a porta padrão 22 reduz grande parte das tentativas automáticas de varredura. Se o provedor oferecer login por chave, configure-o e depois desative o login por senha. No grupo de segurança e no firewall do sistema, libere apenas as portas realmente necessárias e feche as demais. São poucos minutos de trabalho que reduzem continuamente varreduras e tentativas de reutilização de credenciais.
Dois caminhos para o serviço de proxy
Uma opção é usar diretamente um túnel SSH. Não é preciso instalar nada no servidor: o cliente aproveita o serviço SSH existente para encaminhar o tráfego, usando a porta 22 e as credenciais do próprio servidor. A desvantagem é o desempenho apenas mediano; uso prolongado ou muita concorrência pode pesar, por isso funciona melhor para uso temporário ou para poucas contas.
A outra opção é instalar no servidor um serviço de proxy dedicado. O método mais comum é fazer a instalação com um único comando e depois configurar por conta própria a autenticação e a porta. Essa abordagem oferece melhor desempenho e mais controle e é adequada para uso contínuo. Depois da instalação, habilite a inicialização automática; caso contrário, um reinício do servidor fará o proxy parar.
Autenticação e portas
Há três níveis gerais de autenticação, em ordem crescente de segurança: usuário e senha é o mais simples, mas uma senha vazada praticamente entrega o proxy; senha com lista de IPs de origem permitidos costuma bastar no dia a dia; autenticação por chave ou certificado é a mais robusta, porém exige mais configuração e vale o esforço para contas usadas por longos períodos.
Quanto às portas, não basta configurar a porta de escuta do serviço. É necessário liberar essa porta separadamente no firewall do sistema e no grupo de segurança do provedor. São controles independentes, e liberar apenas um é uma causa comum de falha de conexão. Além disso, o endereço de escuta não deve ficar vinculado apenas ao loopback local. Se o teste funciona no próprio servidor, mas não de fora, essa costuma ser a causa.
Conecte no cliente e valide
Crie um novo ambiente na ferramenta de gerenciamento, informe nome e observação — incluir a finalidade da conta e a região-alvo na identificação ajuda bastante quando há muitas contas — e, conforme o tipo de proxy, preencha endereço do servidor, porta, usuário e senha nas configurações do proxy. Execute o teste. Uma mensagem de sucesso indica que o caminho está acessível. Os nomes exatos dos campos dependem da interface da ferramenta.
Passar no teste é apenas o primeiro passo. Abra o ambiente e confirme três pontos.
Primeiro, verifique se o IP de saída é o IP público do servidor. Abra uma página que mostre o IP atual; só está passando corretamente pelo proxy se aparecer o endereço do servidor.
Segundo, confirme se o DNS também passa pelo proxy. Se o DNS continuar sendo resolvido localmente, a informação geográfica exposta pode não coincidir com o IP de saída, tornando inútil a região definida no perfil da conta.
Terceiro, confira se o fuso horário e o idioma combinam com a região de saída. Um IP dos Estados Unidos junto com fuso horário e idioma chineses é uma inconsistência evidente.
O ambiente só deve ser considerado pronto quando as três verificações passarem.
Se não conectar, verifique nesta ordem
Se o teste do proxy falhar logo de início, comece pela conectividade: confirme se a porta está liberada no grupo de segurança e no firewall do sistema. Depois verifique se o serviço de proxy está em execução, principalmente após um reinício. Em seguida confira usuário e senha e confirme o endereço do servidor. Confundir IP público com IP privado é comum.
Se o teste passar, mas as páginas não abrirem, o problema geralmente está no ambiente. Confira se o proxy correto está vinculado e se o DNS não foi alterado de volta para resolução local.
Se estiver lento, determine primeiro se a causa é distância ou largura de banda. Acesse o site de destino diretamente a partir do servidor. Se o servidor em si estiver lento, o problema é a região do nó ou a rota de rede; se o servidor for rápido e o cliente lento, provavelmente falta largura de banda ou há contas demais online ao mesmo tempo.
Como escalar quando o número de contas cresce
Várias contas em um único servidor custam menos, mas todas compartilham o mesmo IP de saída. Se a plataforma identificar relações por faixa de IP, ainda pode haver associação entre as contas. Um servidor por conta custa mais, porém mantém os ambientes totalmente separados e é uma opção mais robusta para contas de maior valor.
Usar uma ferramenta de gerenciamento de ambientes como PurpleMark para vincular uma saída separada a cada conta é mais confiável do que manter uma tabela manual. Pelos preços típicos de servidores leves, uma saída por conta é viável em muitos casos e também evita o trabalho posterior de recriar contas por causa de associação. Mantenha ainda um servidor separado para testes. Não coloque todas as contas na mesma máquina, pois um único ponto de falha pode afetar todas de uma vez.
