Preface

As for how to make the 2-core, 2G RAM, 4Mbps bandwidth Tencent Cloud Lightweight Application Server—which I had to spend a fortune to buy for domain filing—fully shine and perform to its potential, I have been constantly thinking and practicing, placing some important applications that need to run 24 hours a day or hot standby systems (to prevent home data center power outages) for some critical applications on it. Currently, the following have been set up on it: the hot standby source for the www of the filed domain name, Tailscale's DERP relay server, Uptime-Kuma health monitoring, Bark-server alarm system, the mirror site of the blog, and the Bitwarden password management system.

However, I suddenly realized yesterday that if there is a sudden power outage at home, wouldn't my Tencent Cloud server lose its ability to use "magic" (VPN/proxy)? (After all, phones, tablets, and computers can all use warp or "magic" directly, while only the Tencent Cloud server uses proxychains to access the home "magic" via tailscale). This loophole is too big and must be patched. Therefore, the cloud server cannot completely rely on the home "magic"; it needs to be able to stand on its own.

But which method is better? Docker version of OpenWrt and then use OpenClash? I never liked deploying the Docker version of OpenWrt in the first place; it feels like too much hassle—having to set the network card to promiscuous mode, create a macvlan, modify the network card configuration inside the container... and finally install and configure OpenClash... Stability is key on a cloud server, so I didn't want to go through all that trouble. What about Clash for Linux directly? That's not complicated, but there's also a problem: if the upstream level fails (which must be guarded against), the cloud server will go down along with the home network... So, as the industry saying goes, it's best to find something ”heterogeneous”. In the end, I chose warp under Linux. This way, even if the upstream level has issues, it won't affect the cloud server's normal external access, since warp takes an unusual path.

Deploy warp

Install related tools and dependencies (optional)

This step is not mandatory; if you have already installed the relevant tools and dependencies in advance, you can skip it.

apt update
apt install curl wget gnupg dpkg apt-transport-https lsb-release ca-certificates

Install warp according to the official website steps

Add Cloudflare GPG key:

curl -fsSL https://pkg.cloudflareclient.com/pubkey.gpg | sudo gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg

Add this repository to your apt repositories:

echo "deb [signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflare-client.list

Install warp-cli:

sudo apt-get update && sudo apt-get install cloudflare-warp

Check if the warp service is running normally:

systemctl status warp-svc

If normal, it will display as follows:

Note: If installing with the root account, please remove sudo yourself.

Register and enable warp connection

Register warp

warp-cli register #命令提示说以后的版本里命令会变成warp-cli registration new，建议我用这个，不过诡异的是我用这个命令连不上～

At this point, the initial communication between the local warp client and Cloudflare has been completed, but the connection has not been established yet. Use the commandwarp-cli statusYou can see the following display:

2 common ways of usage

Because by default warp will take over all outbound traffic of the host (based on destination IP, not session), the result is that as soon as it connects, all connections accessing the host remotely (not within the local area network) will be interrupted (because the host's responses are intercepted by warp and processed according to its own policy, resulting in ”normal range IPs” being sent out via NAT). For normal locally used terminals, this doesn't have much impact (of course, remote access outside the LAN is also cut off), but for cloud hosts, it is very painful: it disconnects immediately upon connection... and then you can only access it through the VNC access method provided by the cloud host provider.

Note: By default, warp also has excluded destination IPs and Fallback domains, but unfortunately they are of little use for normal public network communication, which is why I said ”normal range IPs” above~. You can use the commandwarp-cli settingsto view:

warp mode (default mode, not recommended unless there are special requirements)

This is the default mode of warp, which directly intercepts all outbound traffic except for the default excluded destination addresses. Generally, locally used terminals are not affected much, but for VPS, normal remote access will be directly interrupted and inaccessible (if unfortunately interrupted, you can disconnect the warp connection in the VNC provided by the cloud host to recover).
Add excluded destination IP addresses (optional):

warp-cli tunnel ip add #给warp添加排除IP、网段，这样即使warp连接以后，添加的网段也可以正常访问主机

Connect to warp:

warp-cli connect #相当于拨号，如果需要断掉wapr连接，使用warp-cli disconnect

Note 1: Why do I say it is not recommended? The only advantage of this method is simplicity, requiring no setup, simple and crude: all outbound traffic goes through warp, but the disadvantages are very prominent:
For VPS, it mainly provides inbound access, and the warp method will invalidate all normal remote access coming from the public network. After all, the vast majority of accessing users have dynamic IP addresses, making it impossible to allow access by adding excluded destination IPs.
For general Linux terminals, it is mainly outbound access, and warp does not have the split tunneling function provided by Clash, which will cause access to domestic websites to be very slow. Of course, if you don't have the need to access domestic websites while using warp, it doesn't matter.

Note 2: In essence, warp uses WireGuard technology and only considers normal outbound access requests (after all, the "wall" is only used by 1 or 2 countries in the network world). So if you really want to use warp more flexibly, you can directly use a WireGuard client to replace warp. However, this method requires reading the WireGuard information in warp first and generating a configuration file. There are corresponding scripts online that can do this, and you can search for them if needed. It's just that I have some technical OCD and don't want to use unofficial scripts casually, so I don't know how stable these scripts actually are. You'll have to try them yourself.

Note 3: The so-called special requirement is when a pure IPv4 device wants to obtain IPv6 outbound access capability, or a pure IPv6 device wants to obtain IPv4 outbound access capability. This is suitable for using warp mode (actually, in proxy mode, having the system globally go through warp's socks5 proxy also works, it's just that a few applications still do not support global proxy).

proxy mode (recommended mode)

The safest way is not to adopt the default warp method of taking over all outbound communication, but to use warp as a proxy. In this way, you only need to set warp's proxy in the system. This mode is especially recommended for cloud hosts, as it is safe and flexible.
Set warp's mode to proxy and set the proxy port:

warp-cli mode proxy #设置warp工作模式为proxy模式
warp-cli proxy port 56789 #如果需要指定代理端口，则使用该命令指定，不指定默认40000

Connect to warp:

warp-cli connect #如果需要断掉wapr连接，使用warp-cli disconnect

Then check the connection status:

warp-cli status

Then check the local connection status:

netstat -ntpl

The red box in the image above shows the address and port of the proxy service generated by WARP. Let's do a comparison test:
Normal accesshttps://ip.gs, and the results are as follows:

You can see that the tested IP address is the public IP address of my cloud server.
Access via the socks5 proxy generated by warp:

You can see that the tested IP address has changed to the address after warp NAT.

---

You can also test the IPv6 access capability I mentioned above.

Testing IPv6 reachability during normal access (Tencent Lightweight Cloud Server does not provide IPv6 addresses, probably costs extra):

Testing IPv6 reachability using the socks5 proxy generated by warp:

So, both proxy mode and warp mode can give a single-stack host dual-stack outbound access capability. Of course, which access method is ultimately used depends on the system's own v4 and v6 priority settings and whether DNS resolution supports both A and AAAA records.

I won't go into detail here about how to set up a proxy in Debian, as there are many tutorials online. However, please note that some applications only support HTTP or HTTPS proxies, such as apt and wget, and using a socks5 proxy will throw an error. Therefore, it is best to deploy gost to convert warp's socks5 proxy into an HTTP proxy for applications that do not support socks5 proxies but only support HTTP proxies.

In fact, warp has other modes, which can be viewed using the following command:

warp-cli mode -h

The displayed content is as follows:

However, for most people, only warp mode and proxy mode are the most commonly used. If you are interested in other modes, you can research them on your own.

Advanced usage: Use warp+ through zero trust (optional)

Normally used warp is just regular warp. If it is used through Zero Trust Teams, it will be warp+. Of course, the premise is that Cloudflare's Zero Trust and its warp client have been set up properly (see article:Home Data Center Series: Make Rational Use of Cloudflare WARP to Improve Your Website Access Speed (Desktop Version))。

---

Optional: Delete existing registration information (a boon for OCD sufferers)

warp-cli registration delete

---

Registering warp to Zero Trust Teams under CLI is a bit more troublesome than the desktop version. There are 2 methods:
Register directly using the Teams name (not recommended)

warp-cli teams-enroll teams-id

The troublesome part of this method is:
a. The root user cannot use it; to use it this way, a user with general permissions must be added.
b. This method requires URL authentication, and accessing URLs under CLI is very troublesome, for example, using w3m:

It was a real pain.
Register using a token (recommended)

This method requires first obtaining the token for Teams registration (note that this is time-sensitive). Access the following link on a host with a browser:

https://[teams-id].cloudflareaccess.com/warp 

For example, using the Chrome browser, open Developer Tools, access the link above, and when the following interface appears:

In the Elements menu of Developer Tools, the red-boxed part in the ”body section" of the image below is the token:

warp-cli registration token xxxx

The result is as follows:

At this point, run the command:

warp-cli settings list

You can see that the warp client configuration you set up in Cloudflare's Zero Trust has been imported, and you can also see that it has joined Teams:

Then, following the same logic as before, you need to set warp to proxy mode. However, since you are now part of an organization, you can't just do whatever you want, so you need to configure it in Zero Trust.
In ”Settings” - “WARP Client”:


Then add the operating system requirements. I set Linux to use proxy mode, while others use warp mode. Here, you can also set specific versions for the operating system (though it's usually not necessary to be so detailed; this is only needed for large organizations):

This is the most critical part, select ”Proxy mode"

Finally, click the button in the red box at the very bottom to create the profile:

Of course, you can also configure policies for other systems in this way. I use proxy for Linux, and warp for other desktop systems:

In this way, different operating systems using the warp client to connect via Zero Trust will adopt different modes based on the pre-set policies, which is very convenient.
Finally, use the commandwarp-cli connectto connect and verify the effect:

Note: There used to be a commandwarp-cli enable-always-on , which could keep the warp connection active at all times. However, it has been deprecated now. But if your warp is already connected, it will still automatically connect after restarting the host, so it doesn't really matter.

Afterword

In fact, enabling warp's proxy mode on a lightweight server is just the first step. There are many flexible ways to use it in the future, such as using the -F parameter via gost deployed on the lightweight server to set warp's socks5 proxy as the upstream proxy (for detailed gost configuration, see:Home Data Center Series - Using gost to Build Your Own Proxy Server and Forwarding Proxy Chains)

This article is for deploying warp on the Linux CLI version. For deploying warp on the desktop version, see:Home Data Center Series: Make Rational Use of Cloudflare WARP to Improve Your Website Access Speed (Desktop Version)。