配置搭好了trojan，历经步骤为安装必要环境，申请letsencrypt证书，修改配置文件(修改了local_addr 和cert key的地址)，trojan客户端是1.13，但是有几个问题 1.经测试vps运营商为hostwind搭建v2ray的tls付费域名速度达50M，现在用的v2ray+mkcp速度是100M,但我用linode搭建tls无论v2ray或trojan速度很慢，速度均在300k至500k，甚至满足不了流畅浏览网页的需求，域名解析服务器用的dnspod或付费域名的服务器也很慢，所有排除的DNS解析的原因 2.看起来trojan客户端并无异常，只是不少是disconnected，windows直接ping域名是可以ping通的，无论是国内或国外的网站ping，都可以ping通 想不出解决办法，所以来提问题 感谢

Build and Install

Type in

mkdir build cd build/ cmake .. make ctest sudo make install

root@11:~/trojan/build# make install make: *** No rule to make target 'install'. Stop.

Welcome to trojan 1.14.0 [2019-12-30 17:27:22] [FATAL] fatal: set_option: Protocol not available [2019-12-30 17:27:22] [FATAL] exiting. . .

交叉编译的，在R6300V2上运行不了。

• [x] I certify that I acknowledge if I don't follow the format below or I don't check this box, my issue will be closed immediately without any notice.

It would be nice to have tproxy support to accept traffic from iptables, in this case it could act as a transparent proxy for LAN network.

reference: https://www.kernel.org/doc/Documentation/networking/tproxy.txt

Dear @GreaterFire,

Thanks for this great project. I have gone though the following link and successfully tested setup trojan before nginx. https://github.com/trojan-gfw/trojan/issues/67

But as trojan doesn't support bind multiple certificates, and I have the request of hosting different websites(https) for different domains on the same server hosting trojan. So I hope to setup trojan behind nginx as nginx can support virtual servers. Can you share some sample config of nginx and trogan to help with this scenario.

Thanks in advance.

In additional, for socks5 problem on windows mentioned in the link below. https://github.com/trojan-gfw/trojan/issues/76 Based on my understanding, the advantage of sock5 is that it supports remote dns resolving comparing with socks4.
v2ray has a configuration of "sniffing" which is quite useful under windows. In this case, even ie can work without third-party apps. Hope it helps.

Cheers, Kevin

因为 443 端口需要提供其他服务，所以用 Nginx 做的代理。 Trojan server 启动监听 445 端口，配置 Nginx 片段:

server {
	listen 443 ssl;
	ssl on;
	ssl_certificate /etc/letsencrypt/live/www/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/www/privkey.pem;
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers HIGH:!aNULL:!MD5;
	server_name 我的域名;
	location / {
		proxy_pass http://127.0.0.1:445;
	}
}

Trojan server config:

{
	"run_type": "server",
	"local_addr": "0.0.0.0",
	"local_port": 445,
	"remote_addr": "127.0.0.1",
	"remote_port": 80,
	"password": [
		"@777m777w"
	],
	"log_level": 0,
	"ssl": {
		"cert": "/etc/letsencrypt/live/www/fullchain.pem",
		"key": "/etc/letsencrypt/live/www/privkey.pem",
		"key_password": "",
		"cipher": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
		"prefer_server_cipher": true,
		"alpn": [
			"http/1.1"
		],
		"reuse_session": true,
		"session_ticket": false,
		"session_timeout": 600,
		"plain_http_response": "",
		"curves": "",
		"dhparam": ""
	},
	"tcp": {
		"prefer_ipv4": false,
		"no_delay": true,
		"keep_alive": true,
		"fast_open": false,
		"fast_open_qlen": 20
	},
	"mysql": {
		"enabled": false,
		"server_addr": "127.0.0.1",
		"server_port": 3306,
		"database": "trojan",
		"username": "trojan",
		"password": ""
	}
}

Trojan client config:

{
	"run_type": "client",
	"local_addr": "127.0.0.1",
	"local_port": 1080,
	"remote_addr": "我的域名",
	"remote_port": 443,
	"password": [
		"@777m777w"
	],
	"append_payload": true,
	"log_level": 0,
	"ssl": {
		"verify": true,
		"verify_hostname": true,
		"cert": "www/fullchain.pem",
		"cipher": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305-SHA256:ECDHE-RSA-CHACHA20-POLY1305-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:RSA-AES128-GCM-SHA256:RSA-AES256-GCM-SHA384:RSA-AES128-SHA:RSA-AES256-SHA:RSA-3DES-EDE-SHA",
		"sni": "",
		"alpn": [
			"h2",
			"http/1.1"
		],
		"reuse_session": true,
		"session_ticket": false,
		"curves": ""
	},
	"tcp": {
		"no_delay": true,
		"keep_alive": true,
		"fast_open": false,
		"fast_open_qlen": 20
	}
}

Trojan 服务器一直提示握手失败:

[2019-02-21 16:48:54] [ERROR] 183.83.69.87:1653 SSL handshake failed: wrong version number [2019-02-21 16:48:54] [INFO] 183.83.69.87:1653 disconnected, 0 bytes received, 0 bytes sent, lasted for 0 seconds

请问我应该如何配置代理转发?

I have setup the trojan on client mode, and it works like a wonder, but then I changed the mode to nat and setup the iptables with following rules:

#!/bin/bash
# Create an iptable chain PROXY
iptables -t nat -N PROXY

# Allow connection for the proxy itself
iptables -t nat -A PROXY -m owner --uid-owner $(id -u $1) -j RETURN

# Allow connection to reserved networks
iptables -t nat -A PROXY -d 0.0.0.0/8 -j RETURN
iptables -t nat -A PROXY -d 10.0.0.0/8 -j RETURN
iptables -t nat -A PROXY -d 127.0.0.0/8 -j RETURN
iptables -t nat -A PROXY -d 169.254.0.0/16 -j RETURN
iptables -t nat -A PROXY -d 172.16.0.0/12 -j RETURN
iptables -t nat -A PROXY -d 192.168.0.0/16 -j RETURN
iptables -t nat -A PROXY -d 224.0.0.0/4 -j RETURN
iptables -t nat -A PROXY -d 240.0.0.0/4 -j RETURN 

# redirect the rest to the proxy port
iptables -t nat -A PROXY -p tcp -j REDIRECT --to-ports $2

# redirect tcp to PROXY 
iptables -t nat -A OUTPUT -p tcp -j PROXY

and executed sudo ./install_iptables proxy 1080, and I also modified the systemd config file to run trojan with user proxy. And it doesn't seem to be working. The log shows something like this:

Oct 02 16:58:02 some-pc trojan[6691]: [2019-10-02 08:58:02] [INFO] 192.168.0.178:47374 disconnected, 0 bytes received, 0 bytes sent, lasted for 0 seconds
Oct 02 16:58:02 some-pc trojan[6691]: [2019-10-02 08:58:02] [ERROR] 192.168.0.178:47376 unknown protocol
Oct 02 16:58:02 some-pc trojan[6691]: [2019-10-02 08:58:02] [INFO] 192.168.0.178:47376 disconnected, 0 bytes received, 0 bytes sent, lasted for 0 seconds
Oct 02 16:58:02 some-pc trojan[6691]: [2019-10-02 08:58:02] [ERROR] 192.168.0.178:47378 unknown protocol
Oct 02 16:58:02 some-pc trojan[6691]: [2019-10-02 08:58:02] [INFO] 192.168.0.178:47378 disconnected, 0 bytes received, 0 bytes sent, lasted for 0 seconds
Oct 02 16:58:02 some-pc trojan[6691]: [2019-10-02 08:58:02] [ERROR] 192.168.0.178:47380 unknown protocol
Oct 02 16:58:02 some-pc trojan[6691]: [2019-10-02 08:58:02] [INFO] 192.168.0.178:47380 disconnected, 0 bytes received, 0 bytes sent, lasted for 0 seconds
Oct 02 16:58:26 some-pc trojan[6691]: [2019-10-02 08:58:26] [INFO] 127.0.0.1:60148 disconnected, 42775 bytes received, 5018 bytes sent, lasted for 64 seconds
Oct 02 16:58:51 some-pc trojan[6691]: [2019-10-02 08:58:51] [ERROR] 192.168.0.178:60544 unknown protocol
Oct 02 16:58:51 some-pc trojan[6691]: [2019-10-02 08:58:51] [INFO] 192.168.0.178:60544 disconnected, 0 bytes received, 0 bytes sent, lasted for 0 seconds

and the browser prints a secure connection error:

Secure Connection Failed
An error occurred during a connection to www.google.com. PR_END_OF_FILE_ERROR

What's the problem with my setting? Do I need to also redirect udp packets to the proxy port?

这样装蒜是不是装的不太像 XD

测试用的ecc证书

客户端配置就是默认的

"cipher": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305-SHA256:ECDHE-RSA-CHACHA20-POLY1305-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:RSA-AES128-GCM-SHA256:RSA-AES256-GCM-SHA384:RSA-AES128-SHA:RSA-AES256-SHA:RSA-3DES-EDE-SHA",

服务端hello返回的是这个

我认为这个顺序应该跟客户端发送的一样才更科学吧.

I would like to invite you to the discussion of the rationales and ideas for a better circumvention protocol.

Many of the points below can have better context with citations but I try to keep it informal this time.

Why use TLS

Security

The Shadowsocks specification has been reinventing cryptography to make up for apparent vulnerabilities from various probing attacks. It among other similar protocols try to recommend specific cipher suites and cryptographic configurations without professional analysis and audit. The fact that the Shadowsocks spec was fixed again and again with faulty cryptographic designs shows how hard it is to reinvent cryptography and why obfuscation is not possible without certain level of security.

This subject has been much better researched and engineered for years as TLS. TLS provides confidentiality, authentication, and integrity. It protects against replay attack. It has mature and high performance and cross-platform implementations. It is only sensible to adopt commonly used best practices. Those who do not understand TLS are doomed to reinvent it, poorly.

Obfuscation

What Shadowsocks is doing is no different from Tor's pluggable transports, e.g. ScrambleSuit and obfs4, which have designed custom cryptographic protocols to replace Tor's default TLS stack, except that Tor's protocols are scholarly peer-reviewed.

The assumption of these Tor PT protocols is that if the wire data look as random as possible (above the transport layer) it would be impossible to identify or classify. This assumption has its limitation. It is shown that random packet padding actually becomes a feature in itself and enables new entropy-based attacks.

The bigger picture is that most traffic on the Internet does not look random. If an obfuscation protocol makes the data too random it attracts additional scrutiny. A thought experiment: the GFW intercepts 60% HTTP, 30% TLS, and 10% unrecognized high-entropy traffic. After the initial coarse traffic classification, the 10% traffic gets redirected for additional analysis, where more advanced methods become affordable.

The obvious solution is to obfuscate above the transport layer inside real TLS. By moving the protocol up the layer, traffic classification at the transport layer is less effective and the obfuscated traffic is less likely to be scrutinized by being of a larger traffic class. (Note that it must be real TLS. Mimicry of HTTP (or TLS) has been shown to be easily detected.) I think this is part of the reason Meek (plain HTTPS proxy with fake TLS SNI) is given more attention at Tor. As more traffic moves to TLS this effect becomes more pronounced.

Problems of TLS

Information leak

TLS is much more complex than TCP and give off much more information, mostly in TLS parameters in ClientHello and ServerHello, state transition, and certificates.

• TLS parameters: Enable fingerprinting attacks. This can be mitigated by capturing common browsers' traffic and reusing the same parameters. It is also easy to verify this mitigation.
• State transition: Enables deeper fingerprinting. This can be mitigated by using the same TLS library as the browser's. ShadowsocksR's forged TLS handshakes are easy to detect by examining protocol dynamics (example).

In principles these protocol behaviors can be imitated perfectly by reusing a browser's TLS stack and it is easy to verify the imitation locally.

• Certificates: They are identifiers themselves and the parameters used to create them also leak information. Possible mitigation options:
  • No certificates (TLS-PSK/TLS-SRP). TLS without certificates would be a unique traffic feature because this is rarely used.
  • Self-signed certificates. Must use certificate pinning otherwise insecure from MitM attacks.
  • Certificates signed with self-signed CA (not in browsers' default chain of trust). Could be an option as TLS middleboxes and organizations (e.g. 12306.cn) tend to use it.
  • Free SSL certificates (Let's Encrypt, StartSSL, et al.).
  • Paid SSL certificates.

GFW people have proposed to prioritize traffic for more advanced analysis by a "trustworthiness" ranking of the certificates. This is essentially network-layer host behavior analysis applied at the TLS layer and the certificates are the new IP addresses. Indeed IP addresses can also have "trustworthiness" used to prioritize traffic for analysis, e.g. if 99% traffic of a foreign host is with a single domestic host, select it for advanced tunnel traffic classifiers; well-known IP addresses are whitelisted, etc.

Traffic selection is always happening and it's a matter of degree of uniqueness of the certificates. In this sense CA-signed certificates (Let's Encrypt) can be even more unique than self-signed certificates because the former may represent less traffic than the latter. There are no clear wrong options here for circumvention but the choice of best practice remains an open question.

Performance

TLS handshakes introduce additional RTT on top of TCP handshakes. Latency is critical for network performance.

The Shadowsocks protocol has no handshakes and its implementation uses TCP Fast Open which reduces even more handshake RTT. Although TCP Fast Open is not always usable as it is commonly obstructed by middleboxes.

Speaking of RTT, VPNs at the network layer would have the least RTT among proxy schemes, but VPNs' usability is harmed by its requirement to configure the OS network stack. In this sense Shadowsocks' success is partly due to the fact that it requires little sysadmin work which is a reasonable tradeoff for TCP handshake RTT.

There are remedies in TLS for the RTT problem. TLS 1.2 False Start extension reduces handshakes to 1-RTT. TLS 1.3 (draft) introduces a 0-RTT mode. But TLS 1.3 implementations are still not production-ready to match the 0-RTT performance in Shadowsocks protocol (I tried Chromium/BoringSSL, Nginx. Though HAProxy just put out 0-RTT support in 1.8-rc3, I was working with Nginx because it's easier for scripting. I hope I can get them working soon.)

About TCP Fast Open, I found neither Nginx nor HAProxy has implemented it in client mode. Nginx gave an interesting reason: it's better to use persistent connections instead of creating new connections very fast. Shadowsocks creates a new proxy connection for each client request. It is arguable whether multiplexing would be better than that for Shadowsocks, but the benefit is obvious in the case of TLS where the cost of creating new connections is high.

There are two schemes of multiplexing: one is multiplexing multiple streams into a single TCP connection, the other is connection reuse/connection pooling. Mux.Cool used by V2Ray is of the first scheme. The first scheme has a head-of-line blocking problem which increases latency, see this. The second one is used by Nginx as "keepalives." It works like this: For a new client connection, try to use an idle proxy connection in the pool or create a new connection; after the client connection is closed, do not close the proxy connection instead save it into the pool as idle (with an idle timeout).

The Shadowsocks protocol does not allow multiplexing because it cannot distinguish the start and end of streams. Neither does the Trojan protocol but Trojan can be extended to allow this enhancement. To enable multiplexing the protocol can use a similar scheme as HTTP chunked transfer encoding:

• Use a size field of two bytes to indicate the size of the chunk immediately following the size field. A size of zero indicates the end of stream.

Traffic analysis

I agree this is a legitimate threat and deserves attention. There has been a report of a specific TLS-in-TLS proxy being repeatably detected by traffic analysis, but at the same time GFW people have also admitted the limitation of practical traffic analysis (classifiers do not generalize, concept drift, etc.).

The difficulty at the circumvention side is that there is no way to verify the effectiveness of any proposed traffic obfuscation technique in real-world setting and similarly there is no way to compare their relative effectiveness.

Despite the theoretical trouble I think the current recommendation is to implement any basic packet padding scheme, which will be always better than no padding. More adversarial implementations of detectors of traffic obfuscators may prove useful in measuring the strength of them.

Other rationales

• In evaluating the threat of an attack, always examine how feasible for the censor to implement the particular attack, i.e. eliminate simple exploits first.
• Develop a censorship event collection and reporting scheme (e.g. collect traffic flow metadata for replay experiments) so analysis can be empirically grounded instead of based on anecdotes and speculation.
• Develop adversarial testing frameworks (e.g. sssniff) so the strength of obfuscation techniques can be verified and compared.
• Usability matters. Even as we focus more on theoretical attacks we should still think about usability.
• (Also, the old recommendation from WCP was that organization of GFW circumvention efforts should be decentralized and fragmented in nature. Increasingly centralized projects like Shadowsocks become easy targets for censorship research. This is why I do not support centralizing more efforts into the Shadowsocks plugin extension system.)

@GreaterFire @micooz @WANG-lp @bosskwei @wongsyrone

Trojan Version latest version 1.14.1 Describe the bug not really bug but i cant understood how Authenticator works especially hash password

Logs

Feb 7 18:12:11 cbtp trojan[9059]: [2020-02-07 18:12:11] [WARN] IP:PORT valid trojan request structure but possibly incorrect password (15ea5abf0d742d8d5d48d50d936fb70dfbc33cea68910d359549055e)

i tried to make bash script to create account via terminal. addtrojan.sh

CLIENT_NAME="$1" if [ "$CLIENT_NAME" == "" ]; then echo "INPUT USERNAME" read -p "Client name: " -e CLIENT_NAME fi CLIENT_PASS="$2" if [ "$CLIENT_PASS" == "" ]; then echo "INPUT PASSWORD" read -p "Client Pass: " -e CLIENT_PASS fi #hash password pwd=$(echo -n "$CLIENT_PASS" | sha224sum | awk '{print $1}') echo "USE trojan; INSERT INTO users (username, password, quota) VALUES ('$CLIENT_NAME', '$pwd' , '-1');" | mysql -utrojan -ppassmysql;

reference: tutor1 and tutor2

• [ok ] I certify that I acknowledge if I don't follow the format below, or I'm using an old version of trojan, or I apparently fail to provide sufficient information (such as logs, specific numbers), or I don't check this box, my issue will be closed immediately without any notice.

Trojan Version The version of trojan you are using. 1.13.0 Describe the bug A clear and concise description of what the bug is. 服务器和nginx均开启h2情况下，访问网站图片加载失败，去掉h2支持后加载正常 To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior A clear and concise description of what you expected to happen. 图片加载正常 Logs If applicable, add logs to help explain your problem. not trojan request, connecting to 127.0.0.1:80 Environment Where are you running trojan? What is your proxy set up? debian9 nginx Additional context Add any other context about the problem here. h2有bug,开启后ssllab会出现http failure,仅使用http1.1则不会

• [x] I certify that I have read the contributing guidelines and I acknowledge if I don't follow the format below, or I'm using an old version of trojan, or I apparently fail to provide sufficient information (such as logs, specific numbers), or I don't check this box, my issue will be closed immediately without any notice.

Trojan Version v2.6.13

Describe the bug Sometimes when I've added new user or removed other ones, server will crash and putty app will closed, afterward other users also disconnected from their proxy and I cant connect by SSH into server using my proxy profile (that was working well) too. Then it needs to be proxy truned off and connect to SSH and run vasma script, then use again other chooses from vasma script to make everything works...

To Reproduce Steps to reproduce the behavior:

1. Connect to server using ssh (by Putty, etc apps)
2. run vasma script
3. Choose 5
4. Choose 4 for delete some users
5. Choose one of users using 2, 3, etc numbers

Expected behavior Users removing as well and proxy server not crashed...

Environment Nekoray and V2rayN with Proxifier

According to trojan official document, the protocol is defined as following:

+-----------------------+---------+----------------+---------+----------+
| hex(SHA224(password)) |  CRLF   | Trojan Request |  CRLF   | Payload  |
+-----------------------+---------+----------------+---------+----------+
|          56           | X'0D0A' |    Variable    | X'0D0A' | Variable |
+-----------------------+---------+----------------+---------+----------+

1. Why do we convert the binary output of sha224 to hex string?
2. hex(SHA224(password)) length is fixed, Trojan Request length can also be calculated esaily, why do we need to add CRLF at the end of each section?

根据trojan官方文档，协议定义如下：

+-----------------------+---------+----------------+---------+----------+
| hex(SHA224(password)) |  CRLF   | Trojan Request |  CRLF   | Payload  |
+-----------------------+---------+----------------+---------+----------+
|          56           | X'0D0A' |    Variable    | X'0D0A' | Variable |
+-----------------------+---------+----------------+---------+----------+

1. 为什么要把sha224的二进制输出转换为文本十六进制？
2. hex(SHA224(password))为固定长度，Trojan Request也可以轻松计算长度，为什么需要CRLF把不同部分间隔？

Hi. Thanks for your great project. Im in a chimese telegram channel and i asked them that which protocol is the best and undetected. They said that Trojan is being blocked! But everywhere I searched for the answer I saw that people recommend using Trojan over VLESS and VMESS etc. Is it true? If it is, whats the best protocol to use? Does combining protocols with WS help?

Please help me. Thanks

这不是一个Trojan issue，这是专制的issue。

Trojan五岁，两年前被Telegram Trojan Channel拦在外面，一直保持关注。看到随写感想，无奈到此回应。

首先表达感激之情，涓涓细流带来思想的养分，滴水亦知恩！其次，Trojan不死，其变种和发展充分延续着星星之火。某些组织拿捏着分而治之，这类项目注定难以由众小白围绕大大进行声势浩大的开发，fork再fork，derive再derive才是延续下去的主旋律。纵然有很多精致利己主义者，但非所有受迫害者都麻木不仁。Trojan理论正在被广泛的运用，越来越多的人逐渐清醒过来，我们不着急，几代人的时间又如何，终有一天会扯断那根稻草。这是一个新的时代，如果鲁迅先生活在当下，大概率已被思想警察请到友爱部的地下室了，而Trojan理论是回应他们的有力武器。

仅以此表达大火酱不是独身一人在战斗，此项目已经给无数思陷囹圄者带来希望，请相信，他们正在各行各业实践着迈向共同目标！请耐心，观摩着，必要时再添一把火！

致敬Trojan，致敬孤勇者！

• [ ] I certify that I have read the contributing guidelines and I acknowledge if I don't follow the format below or I don't check this box, my issue will be closed immediately without any notice.

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Is this problem relevant to what trojan should care about? Trojan is a protocol implementation, not a full-fledged proxy client. Features such as custom routing will not be accepted.

Describe the solution you'd like A clear and concise description of what you want to happen.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

• [x] I certify that I have read the contributing guidelines and I acknowledge if I don't follow the format below, or I'm using an old version of trojan, or I apparently fail to provide sufficient information (such as logs, specific numbers), or I don't check this box, my issue will be closed immediately without any notice.

Trojan Version 1.16.0

Describe the bug Trojan server declines requests because of incorrect password when the password is correctly saved in mysql database.

To Reproduce Create database and insert a user, attempt to connect with the password.

Logs valid trojan request structure but possibly incorrect password (8fdd806e2faa58d8dd807977987d2f39442b2d0ce0198bd03d8191ab)

Environment ubuntu

Additional context users table:

CREATE TABLE `users` (
  `id` int unsigned NOT NULL AUTO_INCREMENT,
  `username` varchar(64) NOT NULL,
  `password` char(56) NOT NULL,
  `quota` bigint NOT NULL DEFAULT '0',
  `download` bigint unsigned NOT NULL DEFAULT '0',
  `upload` bigint unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `password` (`password`)
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
--
-- Dumping data for table `users`
--
LOCK TABLES `users` WRITE;
/*!40000 ALTER TABLE `users` DISABLE KEYS */;
INSERT INTO `users` VALUES (13,'ali','8fdd806e2faa58d8dd807977987d2f39442b2d0ce0198bd03d8191ab',0,0,0);

my trojan.conf:

    "mysql": {
        "enabled": true,
        "server_addr": "127.0.0.1",
        "server_port": 3306,
        "database": "trojan",
        "username": "trojan",
        "password": "***",
        "key": "",
        "cert": "",
        "ca": ""
    }