Currently, the main ladder used for crossing the wall is hysteria2, which has been running stably for over a month. The configuration file on the server has also been gradually improved according to the needs. Overall, deploying the hysteria2 protocol on a VPS is relatively simple. On the one hand, there are many introduction videos about this protocol on YouTube, and on the other hand, the official website documentation provides clear explanations of the functions of each part of the configuration file. This article is to record some of my personal custom configurations.
Note 1: This article mainly records some content added to the current configuration document and part of the tutorial. For detailed tutorials, you can search on your own or refer to the official website configuration document address: https://v2.hysteria.network/en/docs/advanced/Full-Server-Config/
Note 2: The latest version of hysteria at the time of publication is 2.5.0
Basic Configuration#
# Listening port, can be modified, default is 443
listen: :443
# Self-signed certificate
tls:
cert: /etc/hysteria/server.crt
key: /etc/hysteria/server.key
# Acquire certificate through acme dns
acme:
domains:
- "*.example.com"
email: [email protected]
type: dns
dns:
name: cloudflare
config:
cloudflare_api_token: your token
# Authentication method
auth:
type: password
password: 123456 # Set authentication password, pay attention to password strength
# Disguise method
masquerade:
type: proxy
proxy:
url: https://bing.com # Disguise URL
rewriteHost: true
Both self-signed and CA certificates can be used as the certificates required by the server, but only one type can be included in the configuration file. Choose the one that suits your situation and delete the other from the configuration file to complete the basic server configuration.
Self-signed method#
Generate a self-signed certificate using the following command:
openssl req -x509 -nodes -newkey ec:<(openssl ecparam -name prime256v1) -keyout /etc/hysteria/server.key -out /etc/hysteria/server.crt -subj "/CN=bing.com" -days 36500 && sudo chown hysteria /etc/hysteria/server.key && sudo chown hysteria /etc/hysteria/server.crt
Complete configuration file:
listen: :443
tls:
cert: /etc/hysteria/server.crt
key: /etc/hysteria/server.key
auth:
type: password
password: fdsgfdgfrty63
masquerade:
type: proxy
proxy:
url: https://bing.com
rewriteHost: true
CA certificate#
You can obtain a CA certificate through acme dns, provided that you have your own domain name. The service provider I personally chose is cloudflare. The complete configuration is as follows:
listen: :443
acme:
domains:
- "xxx.xxxxxxxx.xxx"
email: [email protected]
type: dns
dns:
name: cloudflare
config:
cloudflare_api_token: hSxxxxxOlxxxxxxxn8U9-pxxxxxxw7
auth:
type: password
password: sldkjfdsnduhf
masquerade:
type: proxy
proxy:
url: https://bing.com
rewriteHost: true
How to obtain cloudflare_api_token:
-
First, log in to your personal cloudflare account.
-
Go to your profile page: https://dash.cloudflare.com/profile
-
Create an API token and use the Edit Zone DNS template to obtain the API token.
Outbound Rules#
Hysteria2 supports three types of outbound: direct, socks5, and http.
In general, no configuration is needed. However, if your server IP cannot access certain websites normally, you can use the socks5 proxy of warp in conjunction with the ACL function in hysteria2 to achieve outbound traffic diversion.
You can refer to the following content for the part that needs to be added in the configuration file:
outbounds:
- name: warp
type: socks5
socks5:
addr: 127.0.0.1:40000
acl:
inline:
- warp(geosite:google)
- direct(all)
First, I opened the warp socks5 proxy on port 40000 on the server, and then configured an outbound rule named "warp" in the outbounds section. This way, by adding - warp(xxxx)
in the acl section according to the documentation format, you can let the traffic go through the warp proxy for outbound, and the function of - direct(all)
is to let the remaining traffic go directly outbound.
Protocol Sniffing#
This is a feature added in the latest version 2.5.0, which solves the problem that the outbound rules in my previous server configuration cannot take effect. The reference configuration provided by the official is as follows, you only need to modify the ports:
sniff:
enable: true
timeout: 2s
rewriteDomain: false
tcpPorts: 80,443,8000-9000
udpPorts: all
Summary#
This is my first time writing this kind of blog, and there are already many related tutorials, so this article is just a simple record and sharing of the features I have used personally. There are still many features that can be configured, and I will continue to update this article in the future as the version updates and my personal experience increases.