Self-host Relay Service with CDN

Nowadays, many relay services exist, but they can't ensure your data security. Around 10% of websites still use HTTP, and traffic to those websites is transparent to relay providers. I don't trust any public relay services. Self-host relay service is a good alternative.

Single server. You can choose any relay protocol you like and deploy it on a trusted server. However, depending on a single source is dangerous. For example, your ISP might block heavy traffic toward an unauthorized server. In addition, your experience may vary when traveling to different areas.

Multi-server. Deploying your relay service to several servers in different locations may be a solution. As a reference, many public relay services have many servers in other regions. However, such a solution is more costly.

Single server with CDN. Fortunately, CDNs can provide a large number of servers that we can utilize. I have found a way to build a self-host relay service with the help of CDN. In the end, we will have a relay service that benefits from CDN's fast delivery and has other advantages:

Block-free
Cost savings
Increased reliability

As a Wormhole. CDN plays the role of wormhole in our relay service, which means it works as a shortcut between devices and our server. For some reason, the traffic to our server might be congested or even blocked. We want CDN to forward the traffic as an end-to-end channel with better quality and security.

CDN won't forward every package it receives. Many cloud service providers only allow their CDN to go with HTTP and HTTPS protocols. In addition, they may also support WS (WebSocket) and WSS (WebSockets over SSL/TLS) since many sites use them as standard communication protocols.

We should choose a relay protocol wisely for maximal CDN compatibility and security. The protocol must depend on HTTP(S)/WS(S). Trojan and Vmess are two popular WS-based protocols. In this article, I will use them to demonstrate how our service works.

As a result, relay applications on devices will wrap the traffic into Trojan/Vmess packets and then pack them with WebSocket and send them to CDN. CDN will forward the packets to our server using the back-to-origin policy.

Many relay services suffer from congested lines. Some "PRO" service uses better public lines to solve congestion. You may have heard of CN2 GIA, IPLC, or similar public lines. But there're more lines like AWS (Amazon) and Azure (Microsoft), which are not accessible to the public. Our relay services with CDN can leverage those private lines to gain better network quality.

Traffic can use the ad-hoc CDN channel instead of public lines between two regions. Furthermore, we can obtain an ad-hoc back-to-origin line for free if we choose a server and CDN provided by the same cloud service.

Anti-blocking. ISP is unlikely to block the traffic to neighbor CDN nodes since they are standard services to all users. Pattern recognition blocking algorithms won't work since they look just like regular WebSocket traffic with TLS encryption. ISP won't supervise the traffic after neighbor CDN nodes.

We don't trust any public relay services since they are black-box to us. In our self-host relay service, security is a first-class target.

TLS. To ensure ISP not be able to monitor the traffic, we use TLS encryption to guarantee WebSocket packets travel to neighbor CDN nodes securely. CDN will decrypt the TLS traffic and get the WebSocket packets.

AEAD. CDN might be able to scan information from our packets. That's why we encrypt the traffic with AEAD. AEAD is a symmetric encryption algorithm used to encrypt the original TCP/UDP packets supported by VMess/Trojan protocol.

If we trust the cloud service provider, AEAD is unnecessary. For example, I'm using AWS, which provides a CloudFront service and EC2 instances. I trust Amazon won't scan my traffic, and the private link between CloudFront and EC2 is not vulnerable to attacks. So AEAD is disabled on the link. Also, I won't need TLS on the private link either.

Building a self-host relay service with CDN is simple if we understand its principle. Before we start, let's do a final check.

In the following steps, I will use:

AWS EC2 as the remote server
AWS CloudFront as the CDN service
Vmess as the relay protocol
Xray as the server APP
Clash as the client APP

Server configuation

First, we need to configure our server to open a relay service based on Vmess-over-WebSocket. I prefer a docker image provided by xray.

mkdir ~/xray
vim ~/xray/config.json
docker run -d -v ~/xray:/etc/xray --network=host --restart=always teddysun/xray

The config JSON file should look like this:

config.json

{
  "inbounds": [
    {
      "port": 10090,
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "49dd2152-17af-436b-8539-fe6adff56529",
            "alterId": 0
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
          "path": "/api/v1"
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

You should use a UUID generator to generate your unique ID and replace the 49dd2152-17af-436b-8539-fe6adff56529 with it. You can also change the WS path /api/v1 and the port number 10090 to anything you like.

CDN configuration

Obtain an SSL certificate. Since the communication between devices and CDN use TLS, we need to obtain an SSL certificate. I used AWS Certificate Manager to obtain the certificate. It's straightforward, and you can get certification to a set of domains (e.g., *.cdn.whexy.com) than one particular domain.

CDN Settings. After that, we can configure our CDN. Use a proper domain name like gobear.cdn.whexy.com as an alternative CNAME with the corresponding certificate we got before. Change the HTTP port to 10090 as the port number of our services. You will get a CDN-specific domain afterward (e.g., tkn.cloudfront.net).

DNS Settings. Go to the DNS settings of your domain. Add a CNAME record of gobear.cdn.whexy.com pointing to the CDN-specific domain.

Device configuration

I'm using Clash as a client. Use the following config as an example to connect to our server:

- {
    name: CDN-relay,
    server: gobear.cdn.whexy.com,
    port: 443,
    type: vmess,
    uuid: 49dd2152-17af-436b-8539-fe6adff56529,
    alterId: 0,
    tls: true,
    skip-cert-verify: true,
    network: ws,
    ws-opts:
      { path: /api/v1, headers: { Host: gobear.cdn.whexy.com } },
    udp: true,
  }

Now we have a self-host relay service with CDN. The client will automatically connect to the nearest CDN node with the help of a geographical domain resolve service (DNS).

However, we shouldn't depend on geographical DNS since it won't always reply with the address of the fastest node. If we know the IP list of CDN nodes, we can use the client APP to perform a speed test.

To do so, replace the server field in the client configuration file with the IP addresses of CDN nodes. I'm not going to explain how to get the address list in this post. So I'll leave that part up to you to complete.

推荐订阅源

Whexy Blog

Server configuation

CDN configuration

Device configuration