Tutoriais de VPS
Tutorial completo para montar um servidor proxy em VPS (2026): V2Ray / Xray / Shadowsocks da escolha da máquina à entrada em produção
Este é um guia de implantação de servidor proxy em VPS para cenários de uso pessoal legítimo, acesso remoto empresarial e transmissão criptografada. O artigo parte dos limites de conformidade, da escolha de data center e rota e da linha de base de segurança, explica separadamente as abordagens de implantação do Xray (VLESS + Reality) e do Shadowsocks e acrescenta exposição de portas, rotação de logs, atualização de versões, rollback, monitoramento e uma lista de verificação de aceitação antes da entrada em produção, para evitar que uma implantação por script de um clique se torne difícil de manter depois de entrar em produção.
Muitas pessoas que montam um serviço proxy em um VPS pela primeira vez só se preocupam com "consegue conectar". Depois que ele realmente entra em produção, os problemas geralmente não são os próprios comandos de instalação, mas rotas instáveis do data center, SSH exposto, senhas fracas, logs fora de controle, falta de um plano de rollback ou não saber por onde começar a diagnosticar quando o serviço apresenta problemas.
Este artigo organiza um processo com mentalidade de produção: primeiro esclarecer os limites de uso, depois escolher o VPS e o sistema, em seguida estabelecer uma linha de base de segurança e, por fim, implantar o Xray ou o Shadowsocks e aceitá-lo com métricas quantificáveis. O objetivo não é acumular comandos, mas tornar este nó proxy em VPS estável, sustentável e reversível.
Este artigo destina-se apenas a cenários lícitos e em conformidade, como transmissão criptografada de uso pessoal, acesso remoto empresarial e verificação de conectividade em ambientes de teste. Cumpra as leis e regulamentos do seu local, os termos do seu provedor e as normas de uso da rede.
Um servidor proxy em VPS é adequado para estes cenários:
- Transmissão criptografada entre dispositivos pessoais;
- Pontos de entrada de acesso remoto para empresas ou equipes;
- Testes de conectividade de serviços entre regiões;
- Desenvolvimento temporário, depuração e verificação de qualidade de rede;
- Negócios lícitos com requisitos de privacidade e segurança no link de transmissão.
Não é recomendável tratá-lo como um serviço de caixa-preta de "instalar e esquecer". Um nó proxy é, essencialmente, um ponto de entrada de rede exposto à internet pública por longo prazo; assim como serviços web, bancos de dados e SSH, ele precisa de privilégio mínimo, gestão de logs, atualizações periódicas e monitoramento de anomalias.
Se o seu objetivo é apenas um teste temporário, não é recomendável comprar um plano de longo prazo; se precisar de uso estável, priorize provedores de VPS que ofereçam snapshots, reinstalação, IPv6, firewall e estatísticas de tráfego.
A experiência de um nó proxy depende principalmente do caminho de rede, e não simplesmente da CPU ou da memória. Recomendações gerais:
| Item | Recomendação |
|---|---|
| CPU / Memória | Começar com 1-2 vCPU, 1-2 GB de RAM |
| Disco | 20 GB ou mais SSD / NVMe |
| Sistema | Ubuntu 22.04 LTS ou Debian 12 |
| Rede | Priorizar latência no horário de pico, perda de pacotes e rota de retorno |
| Data center | Quanto mais próximo da sua principal região de uso, melhor |
| Recursos | Suporte a snapshots, reinstalação, firewall, estatísticas de tráfego |
Não olhe apenas para parâmetros de pico como "largura de banda de 1 Gbps". O mais importante é:
- Se há perda de pacotes no horário de pico;
- Se a rota de retorno faz desvios;
- Se há limitação de velocidade ou QoS evidentes;
- Se o provedor permite o seu cenário de uso;
- Se o IP está limpo e não é identificado com frequência como proxy de alto risco ou nó de abuso.
Antes da entrada em produção, recomenda-se ler primeiro estes artigos para não comprar na direção errada:
- Por que o VPS fica lento no horário de pico (2026): como distinguir congestionamento de rota, overselling e mudanças na rota de retorno
- Como consultar listas negras e reputação de IP de VPS (2026): se comprar um IP sujo, não se apresse a montar sites ou fazer login em contas
- O serviço VPS iniciou, mas não é acessível pela internet (2026): como diagnosticar portas, firewall, grupos de segurança e endereços de escuta
Não execute primeiro scripts de um clique. Ao receber uma máquina nova, recomenda-se concluir primeiro três coisas: usuário comum, chaves SSH e firewall.
adduser appops
usermod -aG sudo appops
Copie a chave pública SSH na sua máquina local:
ssh-copy-id appops@你的服务器IP
Depois de confirmar que o usuário comum consegue fazer login, modifique a configuração do SSH:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd
Ao mexer na configuração do SSH, não feche o terminal atual. Abra outra janela, verifique se consegue fazer login e só então saia da conexão antiga.
sudo apt update
sudo apt install -y ufw fail2ban curl wget unzip jq
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo systemctl enable --now fail2ban
Se você usar uma porta diferente de 443, também deve abrir explicitamente a porta correspondente:
sudo ufw allow 你的端口/tcp
Também verifique o grupo de segurança no console do provedor de nuvem. Muitos problemas de "o servidor já escuta localmente, mas não é acessível pela internet" são, na verdade, porque o grupo de segurança não liberou o tráfego.
O Xray é mais adequado para cenários que exigem configuração detalhada e possível expansão futura para múltiplos usuários, múltiplas entradas ou regras de roteamento complexas. Aqui apresentamos a abordagem de implantação e os pontos-chave de operação; não é recomendável copiar diretamente arquivos de configuração de origem desconhecida da internet.
bash <(curl -Ls https://github.com/XTLS/Xray-install/raw/main/install-release.sh)
/usr/local/bin/xray version
Após a instalação, confirme que o serviço systemd existe:
systemctl status xray --no-pager
uuidgen
xray x25519
Guarde pelo menos estas informações:
- UUID;
- private key;
- public key;
- short id;
- serverName;
- porta de escuta;
- caminho de backup do arquivo de configuração.
Recomenda-se colocá-las em um gerenciador de senhas local, e não apenas em um arquivo de texto temporário no servidor.
sudo cp /usr/local/etc/xray/config.json /usr/local/etc/xray/config.json.bak.$(date +%F-%H%M)
Após modificar a configuração, verifique primeiro o formato JSON:
jq . /usr/local/etc/xray/config.json >/dev/null
Depois inicie o serviço:
sudo systemctl enable --now xray
sudo systemctl restart xray
sudo systemctl status xray --no-pager
Verifique os logs:
journalctl -u xray -n 100 --no-pager
Se aparecerem erros de análise de configuração nos logs, faça o rollback do arquivo de configuração primeiro; não continue modificando vários lugares:
sudo cp /usr/local/etc/xray/config.json.bak.时间戳 /usr/local/etc/xray/config.json
sudo systemctl restart xray
A vantagem do Shadowsocks é a configuração simples e o baixo consumo de recursos, adequado para nós pessoais leves. A desvantagem é que sua capacidade de expansão e adaptação a cenários complexos não é tão boa quanto a do Xray.
sudo apt update
sudo apt install -y shadowsocks-libev
Gere uma senha forte:
openssl rand -base64 32
Edite:
sudo cp /etc/shadowsocks-libev/config.json /etc/shadowsocks-libev/config.json.bak.$(date +%F-%H%M)
sudo nano /etc/shadowsocks-libev/config.json
Itens-chave recomendados:
{
"server": "0.0.0.0",
"server_port": 8388,
"password": "替换为强密码",
"timeout": 300,
"method": "chacha20-ietf-poly1305",
"fast_open": false,
"mode": "tcp_and_udp"
}
Inicie e verifique:
sudo systemctl enable --now shadowsocks-libev
sudo systemctl restart shadowsocks-libev
sudo systemctl status shadowsocks-libev --no-pager
journalctl -u shadowsocks-libev -n 100 --no-pager
Se você habilitar UDP, lembre-se de liberar também a porta UDP:
sudo ufw allow 8388/udp
O erro mais comum com nós proxy é "abrir tudo para economizar trabalho". Recomenda-se seguir três princípios:
- SSH permite apenas login por chave;
- As portas de negócio abrem apenas o TCP/UDP realmente necessário;
- Painéis de gestão e monitoramento não devem ser expostos diretamente à internet pública.
Verifique as portas em escuta:
ss -lntup
Verifique o firewall:
sudo ufw status verbose
Verifique de fora se a porta está acessível:
nc -vz 你的服务器IP 443
Se o serviço escuta normalmente no local, mas não é acessível pela internet, diagnostique nesta ordem:
- Se o serviço escuta em
0.0.0.0ou na entrada pública correta; - Se o UFW permite;
- Se o grupo de segurança do provedor de nuvem permite;
- Se o provedor bloqueia a porta;
- Se o endereço, a porta, o UUID e a senha configurados no cliente coincidem.
Antes da entrada em produção, faça pelo menos estas verificações:
systemctl status xray --no-pager
systemctl status shadowsocks-libev --no-pager
journalctl -u xray -n 50 --no-pager
journalctl -u shadowsocks-libev -n 50 --no-pager
Se você implantar apenas um dos serviços, basta verificar o serviço correspondente.
ping -c 20 你的服务器IP
mtr -rwzc 100 你的服务器IP
Recomenda-se registrar três faixas de horário:
- Manhã de dia útil;
- Horário de pico;
- Horário de pico do fim de semana.
Concentre-se na taxa de perda de pacotes, na latência mediana e no jitter, e não apenas em um pico de teste de velocidade.
free -h
df -h
top
journalctl -p warning -n 100 --no-pager
Se a máquina tiver apenas 1 GB de memória, não acumule muitos serviços ao mesmo tempo. Colocar proxy, monitoramento, Docker, banco de dados e painel em um único VPS pequeno faz com que eles facilmente se afetem depois.
Recomenda-se fixar uma janela de manutenção mensal:
sudo apt update
sudo apt list --upgradable
Faça um snapshot antes de atualizar. Especialmente com componentes relacionados à rede, como kernel, OpenSSL, systemd, Xray e Shadowsocks, não atualize de qualquer jeito durante os horários de pico.
Verifique o uso de logs:
journalctl --disk-usage
Limite o journal do systemd:
sudo journalctl --vacuum-time=14d
Para nós de execução prolongada, recomenda-se configurar a rotação de logs para evitar que o disco do sistema fique cheio de logs. Para diagnóstico de disco, consulte:
Faça backup pelo menos de:
/usr/local/etc/xray/config.json;/etc/shadowsocks-libev/config.json;- configuração do SSH;
- regras do firewall;
- parâmetros de conexão do cliente.
Antes de modificar, copie primeiro um backup com carimbo de data e hora; é muito mais confiável do que tentar lembrar o que foi alterado quando surge um problema.
systemctl status xray --no-pager
journalctl -u xray -n 100 --no-pager
Verifique primeiro o formato da configuração, conflitos de porta e problemas de permissão.
ss -lntup
sudo ufw status verbose
Depois verifique o grupo de segurança e a política de portas do provedor.
Não reinstale o sistema primeiro. Registre primeiro mtr, ping, CPU steal e iowait de disco. Muitas vezes é contenção de recursos da rota ou de vizinhos, e não um problema de configuração do software proxy.
Trocar de protocolo não necessariamente resolve. Primeiro verifique a reputação do IP, o ASN, o tipo de data center e o histórico de abuso. Se o seu negócio for sensível à qualidade do IP, confirme antes de comprar as políticas de reembolso, troca de IP e IP de teste.
Os nós proxy são muito sensíveis à qualidade da rota e do IP, e data centers diferentes do mesmo provedor também podem variar muito. Você pode começar procurando IPs de teste ou planos de curto prazo nestes provedores:
Antes de fazer o pedido, confirme pelo menos:
- Se o seu cenário de uso é permitido;
- Se há limites de tráfego e política de uso justo;
- Se há suporte a reembolso ou troca de data center;
- Se são fornecidos IPs de teste;
- Se o desempenho no horário de pico é estável.
Um servidor proxy em VPS não é um projeto que "termina quando o script acaba de rodar". A ordem de implantação verdadeiramente profissional deveria ser:
- Esclarecer cenários de uso lícitos e em conformidade;
- Escolher um VPS com rota e qualidade de IP adequadas;
- Estabelecer primeiro uma linha de base de segurança como SSH, firewall e Fail2Ban;
- Depois implantar Xray ou Shadowsocks;
- Usar portas, logs, mtr e uso de recursos para a aceitação antes da entrada em produção;
- Estabelecer mecanismos de atualização, backup, rollback e manutenção de logs.
Seguindo esta ordem, a primeira implantação levará mais dez minutos, mas depois, quando não conseguir conectar, ficar mais lento ou o serviço falhar ao iniciar, você conseguirá localizar o problema rapidamente em vez de só poder reinstalar a máquina e começar de novo.