Tutoriales de VPS
Tutorial completo para montar un servidor proxy en VPS (2026): V2Ray / Xray / Shadowsocks desde la elección de la máquina hasta la puesta en marcha
Esta es una guía de despliegue de servidor proxy en VPS para escenarios de uso personal legítimo, acceso remoto empresarial y transmisión cifrada. El artículo parte de los límites de cumplimiento, la elección de centro de datos y ruta, y la línea base de seguridad, y explica por separado los enfoques de despliegue de Xray (VLESS + Reality) y Shadowsocks, además de añadir exposición de puertos, rotación de registros, actualización de versiones, reversión, monitoreo y una lista de verificación de aceptación antes de la puesta en marcha, para evitar que un despliegue con script de un solo clic resulte difícil de mantener después de salir a producción.
Muchas personas que montan un servicio proxy en un VPS por primera vez solo se fijan en "si puede conectarse". Una vez que realmente entra en producción, los problemas suelen no ser los propios comandos de instalación, sino rutas inestables del centro de datos, SSH expuesto, contraseñas débiles, registros fuera de control, falta de un plan de reversión o no saber por dónde empezar a diagnosticar cuando el servicio falla.
Este artículo organiza un proceso con enfoque de producción: primero aclarar los límites de uso, luego elegir el VPS y el sistema, después establecer una línea base de seguridad y, por último, desplegar Xray o Shadowsocks y aceptarlo con métricas cuantificables. El objetivo no es acumular comandos, sino hacer que este nodo proxy en VPS sea estable, mantenible y reversible.
Este artículo está dirigido únicamente a escenarios lícitos y conformes, como transmisión cifrada de uso personal, acceso remoto empresarial y verificación de conectividad en entornos de prueba. Cumpla con las leyes y regulaciones de su ubicación, los términos de su proveedor y las normas de uso de la red.
Un servidor proxy en VPS es adecuado para estos escenarios:
- Transmisión cifrada entre dispositivos personales;
- Puntos de entrada de acceso remoto para empresas o equipos;
- Pruebas de conectividad de servicios entre regiones;
- Desarrollo temporal, depuración y verificación de calidad de red;
- Negocios lícitos con requisitos de privacidad y seguridad en el enlace de transmisión.
No se recomienda tratarlo como un servicio de caja negra de "instalar y olvidarse". Un nodo proxy es esencialmente un punto de entrada de red expuesto a internet pública a largo plazo; al igual que los servicios web, las bases de datos y SSH, necesita privilegio mínimo, gestión de registros, actualizaciones periódicas y monitoreo de anomalías.
Si su objetivo es solo una prueba temporal, no se recomienda comprar un plan a largo plazo; si necesita un uso estable, priorice proveedores de VPS que admitan instantáneas, reinstalación, IPv6, firewall y estadísticas de tráfico.
La experiencia de un nodo proxy depende principalmente de la ruta de red, no simplemente de la CPU o la memoria. Recomendaciones generales:
| Elemento | Recomendación |
|---|---|
| CPU / Memoria | Empezar con 1-2 vCPU, 1-2 GB de RAM |
| Disco | 20 GB o más SSD / NVMe |
| Sistema | Ubuntu 22.04 LTS o Debian 12 |
| Red | Priorizar latencia en hora pico, pérdida de paquetes y ruta de retorno |
| Centro de datos | Cuanto más cerca de su región principal de uso, mejor |
| Funciones | Compatibilidad con instantáneas, reinstalación, firewall, estadísticas de tráfico |
No se fije solo en parámetros pico como "ancho de banda de 1 Gbps". Lo más importante es:
- Si hay pérdida de paquetes en la hora pico;
- Si la ruta de retorno da rodeos;
- Si hay limitación de velocidad o QoS evidentes;
- Si el proveedor permite su escenario de uso;
- Si la IP está limpia y no se identifica con frecuencia como proxy de alto riesgo o nodo de abuso.
Antes de la puesta en marcha, se recomienda leer primero estos artículos para no comprar en la dirección equivocada:
- Por qué el VPS se ralentiza en la hora pico (2026): cómo distinguir congestión de ruta, sobreventa y cambios de ruta de retorno
- Cómo consultar listas negras y reputación de IP de VPS (2026): si compra una IP sucia, no se apresure a montar sitios ni iniciar sesión en cuentas
- El servicio VPS se inició pero no es accesible desde internet (2026): cómo diagnosticar puertos, firewall, grupos de seguridad y direcciones de escucha
No ejecute primero scripts de un solo clic. Al recibir una máquina nueva, se recomienda completar primero tres cosas: usuario normal, claves SSH y firewall.
adduser appops
usermod -aG sudo appops
Copie la clave pública SSH en su máquina local:
ssh-copy-id appops@你的服务器IP
Después de confirmar que el usuario normal puede iniciar sesión, modifique la configuración de 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
Al operar con la configuración de SSH, no cierre la terminal actual. Abra otra ventana, verifique que puede iniciar sesión y luego salga de la conexión antigua.
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
Si utiliza un puerto distinto de 443, también debe abrir explícitamente el puerto correspondiente:
sudo ufw allow 你的端口/tcp
También revise el grupo de seguridad en la consola del proveedor de nube. Muchos problemas de "el servidor ya escucha localmente pero no es accesible desde internet" se deben en realidad a que el grupo de seguridad no ha permitido el tráfico.
Xray es más adecuado para escenarios que requieren configuración detallada y posible expansión futura a múltiples usuarios, múltiples entradas o reglas de enrutamiento complejas. Aquí se ofrece el enfoque de despliegue y los puntos clave de operación; no se recomienda copiar directamente archivos de configuración de origen desconocido de internet.
bash <(curl -Ls https://github.com/XTLS/Xray-install/raw/main/install-release.sh)
/usr/local/bin/xray version
Después de la instalación, confirme que el servicio systemd existe:
systemctl status xray --no-pager
uuidgen
xray x25519
Guarde al menos esta información:
- UUID;
- private key;
- public key;
- short id;
- serverName;
- puerto de escucha;
- ruta de respaldo del archivo de configuración.
Se recomienda guardarlos en un gestor de contraseñas local, no solo en un archivo de texto temporal en el servidor.
sudo cp /usr/local/etc/xray/config.json /usr/local/etc/xray/config.json.bak.$(date +%F-%H%M)
Después de modificar la configuración, verifique primero el formato JSON:
jq . /usr/local/etc/xray/config.json >/dev/null
Luego inicie el servicio:
sudo systemctl enable --now xray
sudo systemctl restart xray
sudo systemctl status xray --no-pager
Revise los registros:
journalctl -u xray -n 100 --no-pager
Si aparecen errores de análisis de configuración en los registros, revierta primero el archivo de configuración; no siga modificando varios lugares:
sudo cp /usr/local/etc/xray/config.json.bak.时间戳 /usr/local/etc/xray/config.json
sudo systemctl restart xray
La ventaja de Shadowsocks es su configuración sencilla y bajo consumo de recursos, adecuado para nodos personales ligeros. La desventaja es que su capacidad de expansión y adaptación a escenarios complejos no es tan buena como la de Xray.
sudo apt update
sudo apt install -y shadowsocks-libev
Genere una contraseña fuerte:
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
Elementos clave recomendados:
{
"server": "0.0.0.0",
"server_port": 8388,
"password": "替换为强密码",
"timeout": 300,
"method": "chacha20-ietf-poly1305",
"fast_open": false,
"mode": "tcp_and_udp"
}
Inicie y 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
Si habilita UDP, recuerde permitir también el puerto UDP:
sudo ufw allow 8388/udp
El error más común con los nodos proxy es "abrirlo todo para ahorrar problemas". Se recomienda seguir tres principios:
- SSH solo permite inicio de sesión con clave;
- Los puertos de negocio solo abren el TCP/UDP realmente necesario;
- Los paneles de gestión y monitoreo no deben exponerse directamente a internet pública.
Verifique los puertos en escucha:
ss -lntup
Verifique el firewall:
sudo ufw status verbose
Verifique desde fuera si el puerto es accesible:
nc -vz 你的服务器IP 443
Si el servicio escucha correctamente en local pero no es accesible desde internet, diagnostique en este orden:
- Si el servicio escucha en
0.0.0.0o en la entrada pública correcta; - Si UFW lo permite;
- Si el grupo de seguridad del proveedor de nube lo permite;
- Si el proveedor bloquea el puerto;
- Si la dirección, el puerto, el UUID y la contraseña configurados en el cliente coinciden.
Antes de la puesta en marcha, realice al menos estas comprobaciones:
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
Si solo despliega uno de los servicios, basta con verificar el servicio correspondiente.
ping -c 20 你的服务器IP
mtr -rwzc 100 你的服务器IP
Se recomienda registrar tres franjas horarias:
- Mañana de día laborable;
- Hora pico;
- Hora pico del fin de semana.
Céntrese en la tasa de pérdida de paquetes, la latencia mediana y el jitter, no solo en un pico de prueba de velocidad.
free -h
df -h
top
journalctl -p warning -n 100 --no-pager
Si la máquina solo tiene 1 GB de memoria, no acumule demasiados servicios a la vez. Poner el proxy, el monitoreo, Docker, la base de datos y el panel en un solo VPS pequeño hace que fácilmente se afecten entre sí más adelante.
Se recomienda fijar una ventana de mantenimiento mensual:
sudo apt update
sudo apt list --upgradable
Haga una instantánea antes de actualizar. Especialmente con componentes relacionados con la red como el kernel, OpenSSL, systemd, Xray y Shadowsocks, no actualice a la ligera durante las horas pico.
Verifique el uso de registros:
journalctl --disk-usage
Limite el journal de systemd:
sudo journalctl --vacuum-time=14d
Para nodos de ejecución prolongada, se recomienda configurar la rotación de registros para evitar que el disco del sistema se llene de registros. Para el diagnóstico de disco puede consultar:
Haga copia de seguridad al menos de:
/usr/local/etc/xray/config.json;/etc/shadowsocks-libev/config.json;- configuración de SSH;
- reglas del firewall;
- parámetros de conexión del cliente.
Antes de modificar, copie primero una copia de seguridad con marca de tiempo; es mucho más fiable que intentar recordar qué se cambió cuando surge un problema.
systemctl status xray --no-pager
journalctl -u xray -n 100 --no-pager
Revise primero el formato de configuración, los conflictos de puertos y los problemas de permisos.
ss -lntup
sudo ufw status verbose
Luego revise el grupo de seguridad y la política de puertos del proveedor.
No reinstale el sistema primero. Registre primero mtr, ping, CPU steal y iowait de disco. Muchas veces es contención de recursos de la ruta o de vecinos, no un problema de configuración del software proxy.
Cambiar de protocolo no necesariamente lo resuelve. Primero consulte la reputación de la IP, el ASN, el tipo de centro de datos y el historial de abuso. Si su negocio es sensible a la calidad de la IP, confirme antes de comprar las políticas de reembolso, cambio de IP y prueba de IP.
Los nodos proxy son muy sensibles a la calidad de la ruta y de la IP, y distintos centros de datos del mismo proveedor también pueden diferir mucho. Puede empezar por buscar IP de prueba o planes de corto plazo en estos proveedores:
Antes de hacer el pedido, confirme al menos:
- Si se permite su escenario de uso;
- Si hay límites de tráfico y política de uso justo;
- Si se admiten reembolsos o cambios de centro de datos;
- Si se proporcionan IP de prueba;
- Si el rendimiento en hora pico es estable.
Un servidor proxy en VPS no es un proyecto que "termina cuando el script acaba de ejecutarse". El orden de despliegue verdaderamente profesional debería ser:
- Aclarar escenarios de uso lícitos y conformes;
- Elegir un VPS con ruta y calidad de IP adecuadas;
- Establecer primero una línea base de seguridad como SSH, firewall y Fail2Ban;
- Luego desplegar Xray o Shadowsocks;
- Usar puertos, registros, mtr y uso de recursos para la aceptación antes de la puesta en marcha;
- Establecer mecanismos de actualización, copia de seguridad, reversión y mantenimiento de registros.
Siguiendo este orden, el primer despliegue tardará diez minutos más, pero después, cuando no se pueda conectar, se ralentice o el servicio no inicie, podrá localizar el problema rápidamente en lugar de solo poder reinstalar la máquina y empezar de nuevo.