Complete VPS Proxy Server Setup Guide (2026): Xray, Shadowsocks & Secure.

Many people setting up a proxy service on a VPS for the first time focus only on "can it connect." After it actually goes live, the problems are often not the installation commands themselves, but unstable data center routes, exposed SSH, weak passwords, runaway logs, no rollback plan, or not knowing where to start troubleshooting when the service has issues.

This article organizes a process along production-grade lines: first clarify usage boundaries, then choose the VPS and system, then establish a security baseline, and finally deploy Xray or Shadowsocks and accept it with quantifiable metrics. The goal is not to pile up commands, but to make this VPS proxy node stable, maintainable, and rollback-capable.

This article is intended only for lawful and compliant scenarios such as personal encrypted transmission, enterprise remote access, and connectivity verification in test environments. Please comply with the laws and regulations of your location, your provider's terms, and network usage rules.

1. First Clarify Applicable Scenarios and Boundaries

A VPS proxy server suits these scenarios:

Encrypted transmission between personal devices;
Remote access entry points for enterprises or teams;
Cross-region service connectivity testing;
Temporary development, debugging, and network quality verification;
Lawful business with privacy and security requirements for the transmission link.

It is not recommended to treat it as a "set it and forget it" black-box service. A proxy node is essentially a network entry point exposed to the public internet long-term; like web services, databases, and SSH, it needs least privilege, log management, regular updates, and anomaly monitoring.

If your goal is only temporary testing, buying a long-term plan is not recommended; if you need stable use, prioritize VPS providers that support snapshots, reinstallation, IPv6, firewalls, and traffic statistics.

2. Choosing a VPS: Route Quality Before Paper Specs

The experience of a proxy node depends mainly on the network path, not simply CPU or memory. General recommendations:

Item	Recommendation
CPU / Memory	Start with 1-2 vCPU, 1-2GB RAM
Disk	20GB or more SSD / NVMe
System	Ubuntu 22.04 LTS or Debian 12
Network	Prioritize evening peak latency, packet loss, and return route
Data center	The closer to your main usage region, the better
Features	Supports snapshots, reinstallation, firewall, traffic statistics

Don't just look at peak parameters like "1Gbps bandwidth." What matters more:

Whether there is packet loss during evening peak;
Whether the return route detours;
Whether there is obvious rate limiting or QoS;
Whether the provider allows your usage scenario;
Whether the IP is clean and not frequently flagged as a high-risk proxy or abuse node.

Before going live, it is recommended to read these articles first to avoid buying in the wrong direction:

3. Before Deployment, Establish a Security Baseline

Don't run one-click scripts first. After getting a new machine, it is recommended to complete three things first: a regular user, SSH keys, and a firewall.

adduser appops
usermod -aG sudo appops

Copy the SSH public key on your local machine:

ssh-copy-id appops@你的服务器IP

After confirming the regular user can log in, modify the SSH configuration:

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

When working with SSH configuration, do not close the current terminal. Open a new window, verify you can log in, and then exit the old connection.

3.2 Configure the Firewall and Basic Brute-Force Protection

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

If you use a non-443 port, explicitly open the corresponding port as well:

sudo ufw allow 你的端口/tcp

Also check the security group in the cloud provider's console. Many "the server is listening locally but inaccessible from the internet" problems are actually because the security group has not allowed the traffic.

4. Option A: Xray (VLESS + Reality)

Xray is better suited to scenarios requiring fine-grained configuration and possible future expansion to multiple users, multiple entry points, or complex routing rules. Here we give the deployment approach and operations key points; directly copying configuration files of unknown origin from the internet is not recommended.

4.1 Install Xray

bash <(curl -Ls https://github.com/XTLS/Xray-install/raw/main/install-release.sh)
/usr/local/bin/xray version

After installation, confirm the systemd service exists:

systemctl status xray --no-pager

4.2 Generate Identity Parameters

uuidgen
xray x25519

Save at least this information:

UUID;
private key;
public key;
short id;
serverName;
listening port;
configuration file backup path.

It is recommended to put them in a local password manager, not just in a temporary text file on the server.

4.3 Back Up Before Configuring

sudo cp /usr/local/etc/xray/config.json /usr/local/etc/xray/config.json.bak.$(date +%F-%H%M)

After modifying the configuration, check the JSON format first:

jq . /usr/local/etc/xray/config.json >/dev/null

Then start the service:

sudo systemctl enable --now xray
sudo systemctl restart xray
sudo systemctl status xray --no-pager

Check the logs:

journalctl -u xray -n 100 --no-pager

If configuration parsing errors appear in the logs, roll back the configuration file first; do not keep modifying multiple places:

sudo cp /usr/local/etc/xray/config.json.bak.时间戳 /usr/local/etc/xray/config.json
sudo systemctl restart xray

5. Option B: Shadowsocks (Lightweight, Quick to Start)

Shadowsocks's advantages are simple configuration and low resource usage, suitable for lightweight personal nodes. The downside is that its extensibility and adaptation to complex scenarios are not as good as Xray.

5.1 Installation

sudo apt update
sudo apt install -y shadowsocks-libev

Generate a strong password:

openssl rand -base64 32

5.2 Basic Configuration

Edit:

sudo cp /etc/shadowsocks-libev/config.json /etc/shadowsocks-libev/config.json.bak.$(date +%F-%H%M)
sudo nano /etc/shadowsocks-libev/config.json

Key items recommended:

{
  "server": "0.0.0.0",
  "server_port": 8388,
  "password": "替换为强密码",
  "timeout": 300,
  "method": "chacha20-ietf-poly1305",
  "fast_open": false,
  "mode": "tcp_and_udp"
}

Start and check:

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

If you enable UDP, remember to allow the UDP port as well:

sudo ufw allow 8388/udp

6. Port Exposure Principles: Only Open Required Entry Points

The most common mistake with proxy nodes is "opening everything to save trouble." It is recommended to follow three principles:

SSH allows key login only;
Business ports open only the TCP/UDP actually needed;
Management panels and monitoring panels should not be exposed directly to the public internet.

Check listening ports:

ss -lntup

Check the firewall:

sudo ufw status verbose

Check port reachability from outside:

nc -vz 你的服务器IP 443

If the service listens normally locally but is unreachable from the internet, troubleshoot in this order:

Whether the service listens on 0.0.0.0 or the correct public entry point;
Whether UFW allows it;
Whether the cloud provider's security group allows it;
Whether the provider blocks the port;
Whether the address, port, UUID, and password configured on the client match.

7. Go-Live Acceptance: Don't Just Test "Can Connect" Once

Before going live, do at least these checks:

7.1 Service Status

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

If you deploy only one of the services, just check the corresponding service.

7.2 Network Quality

ping -c 20 你的服务器IP
mtr -rwzc 100 你的服务器IP

It is recommended to record three time slots:

Weekday morning;
Evening peak;
Weekend evening peak.

Focus on packet loss rate, median latency, and jitter, not just a single speed test peak.

7.3 Resource Usage

free -h
df -h
top
journalctl -p warning -n 100 --no-pager

If the machine has only 1GB of memory, don't pile on too many services at once. Putting the proxy, monitoring, Docker, database, and panel all on one small VPS easily causes them to affect each other later.

8. Operations and Maintenance: Updates, Logs, Backups, Rollback

8.1 Regular Updates

It is recommended to set a fixed monthly maintenance window:

sudo apt update
sudo apt list --upgradable

Take a snapshot before upgrading. Especially for network-related components such as the kernel, OpenSSL, systemd, Xray, and Shadowsocks, do not upgrade casually during peak hours.

8.2 Log Control

Check log usage:

journalctl --disk-usage

Limit the systemd journal:

sudo journalctl --vacuum-time=14d

For long-running nodes, it is recommended to configure log rotation to avoid filling the system disk with logs. For disk troubleshooting, see:

What to Do When VPS Docker Fills the Disk (2026): overlay2, Container Logs, Images, and Volume Cleanup Checklist

8.3 Configuration Backup

Back up at least:

/usr/local/etc/xray/config.json;
/etc/shadowsocks-libev/config.json;
SSH configuration;
Firewall rules;
Client connection parameters.

Before modifying, copy a timestamped backup first; it is far more reliable than trying to recall what you changed after a problem occurs.

9. Common Troubleshooting

Service Fails to Start

systemctl status xray --no-pager
journalctl -u xray -n 100 --no-pager

Check configuration format, port conflicts, and permission issues first.

Works Locally but Not Reachable from the Internet

ss -lntup
sudo ufw status verbose

Then check the security group and the provider's port policy.

Noticeably Slower at Evening Peak

Don't reinstall the system first. First record mtr, ping, CPU steal, and disk iowait. Many times it is route or neighbor resource contention, not a proxy software configuration problem.

IP Flagged by Risk Control or Identified as a Proxy

Changing protocols does not necessarily solve it. First check IP reputation, ASN, data center type, and historical abuse records. If your business is sensitive to IP quality, confirm refund, IP replacement, and test IP policies before purchasing.

10. Candidate Providers: Test Before Buying, No Absolute Ranking

Proxy nodes are very sensitive to route and IP quality, and different data centers of the same provider can also differ greatly. You can start by finding test IPs or short-term plans from these providers:

Before ordering, confirm at least:

Whether your usage scenario is allowed;
Whether there are traffic limits and a fair use policy;
Whether refunds or data center changes are supported;
Whether test IPs are provided;
Whether evening peak performance is stable.

Conclusion

A VPS proxy server is not a project that "ends when the script finishes running." A truly professional deployment order should be:

Clarify lawful and compliant usage scenarios;
Choose a VPS with suitable route and IP quality;
Establish a security baseline such as SSH, firewall, and Fail2Ban first;
Then deploy Xray or Shadowsocks;
Use ports, logs, mtr, and resource usage for go-live acceptance;
Establish update, backup, rollback, and log maintenance mechanisms.

Following this order costs an extra ten-plus minutes on the first deployment, but later, when you can't connect, things slow down, or the service fails to start, you can quickly locate the problem instead of only being able to reinstall the machine and start over.

Item

Recommendation

CPU / Memory

Start with 1-2 vCPU, 1-2GB RAM

Disk

20GB or more SSD / NVMe

System

Ubuntu 22.04 LTS or Debian 12

Network

Prioritize evening peak latency, packet loss, and return route

Data center

The closer to your main usage region, the better

Features

Supports snapshots, reinstallation, firewall, traffic statistics

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

1. First Clarify Applicable Scenarios and Boundaries

2. Choosing a VPS: Route Quality Before Paper Specs

3. Before Deployment, Establish a Security Baseline

3.1 Create a Regular User and Disable root Password Login

3.2 Configure the Firewall and Basic Brute-Force Protection

4. Option A: Xray (VLESS + Reality)

4.1 Install Xray

4.2 Generate Identity Parameters

4.3 Back Up Before Configuring

5. Option B: Shadowsocks (Lightweight, Quick to Start)

5.1 Installation

5.2 Basic Configuration

6. Port Exposure Principles: Only Open Required Entry Points

7. Go-Live Acceptance: Don't Just Test "Can Connect" Once

7.1 Service Status

7.2 Network Quality

7.3 Resource Usage

8. Operations and Maintenance: Updates, Logs, Backups, Rollback

8.1 Regular Updates

8.2 Log Control

8.3 Configuration Backup

9. Common Troubleshooting

Service Fails to Start

Works Locally but Not Reachable from the Internet

Noticeably Slower at Evening Peak

IP Flagged by Risk Control or Identified as a Proxy

10. Candidate Providers: Test Before Buying, No Absolute Ranking

Conclusion

Loading…

1. First Clarify Applicable Scenarios and Boundaries

2. Choosing a VPS: Route Quality Before Paper Specs

3. Before Deployment, Establish a Security Baseline

3.1 Create a Regular User and Disable root Password Login

3.2 Configure the Firewall and Basic Brute-Force Protection

4. Option A: Xray (VLESS + Reality)

4.1 Install Xray

4.2 Generate Identity Parameters

4.3 Back Up Before Configuring

5. Option B: Shadowsocks (Lightweight, Quick to Start)

5.1 Installation

5.2 Basic Configuration

6. Port Exposure Principles: Only Open Required Entry Points

7. Go-Live Acceptance: Don't Just Test "Can Connect" Once

7.1 Service Status

7.2 Network Quality

7.3 Resource Usage

8. Operations and Maintenance: Updates, Logs, Backups, Rollback

8.1 Regular Updates

8.2 Log Control

8.3 Configuration Backup

9. Common Troubleshooting

Service Fails to Start

Works Locally but Not Reachable from the Internet

Noticeably Slower at Evening Peak

IP Flagged by Risk Control or Identified as a Proxy

10. Candidate Providers: Test Before Buying, No Absolute Ranking

Conclusion