[GH-ISSUE #4520] [Question] Behavior of "transport.useEncryption" and "transport.tls.enable" setting on client.

gitea-mirror commented

2026-05-05 14:17:37 -06:00

Owner

Originally created by @lcharles123 on GitHub (Nov 1, 2024).
Original GitHub issue: https://github.com/fatedier/frp/issues/4520

Bug Description

The frpc.toml have transport.tls.enable option on general section. Under[[proxies]]section there are a transport.useEncryption option. Both true means two layers of encryption? So transport.tls.enable are enough to encrypting the packets? I want only one layer of encryption, possible the one more simple and fast.
Anyway, thanks for this awesome software!

frpc Version

0.60.0

frps Version

0.60.0

System Architecture

linux/amd64

Configurations

Client:

serverAddr = "server.org"
serverPort = 7000
transport.protocol = "tcp"
transport.ConnectServerLocalIP = "one.local.ip"

transport.tls.enable = true
transport.tls.certFile = "/root/frp_0.60.0_linux_amd64/certs/client.crt"
transport.tls.keyFile = "/root/frp_0.60.0_linux_amd64/certs/client.key"
transport.tls.trustedCaFile = "/root/frp_0.60.0_linux_amd64/certs/ca.crt"

auth.token = "mytoken"

[[proxies]]
name = "net.11."
type = "tcp"
localPort = 4433
remotePort = 4433
transport.useEncryption = true

Server:

bindPort = 7000
quicBindPort = 7000

transport.tls.force = true
transport.tls.certFile = "/etc/frp/server.crt"
transport.tls.keyFile = "/etc/frp/server.key"
transport.tls.trustedCaFile = "/etc/frp/ca.crt"
transport.maxPoolCount = 256

auth.method = "token"
auth.token = "mytoken"

webServer.addr = "127.0.0.1"
webServer.port = 7500

Logs

No response

Steps to reproduce

...

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @lcharles123 on GitHub (Nov 1, 2024). Original GitHub issue: https://github.com/fatedier/frp/issues/4520 ### Bug Description The frpc.toml have `transport.tls.enable` option on general section. Under` [[proxies]] `section there are a `transport.useEncryption` option. Both true means two layers of encryption? So `transport.tls.enable` are enough to encrypting the packets? I want only one layer of encryption, possible the one more simple and fast. Anyway, thanks for this awesome software! ### frpc Version 0.60.0 ### frps Version 0.60.0 ### System Architecture linux/amd64 ### Configurations Client: ``` serverAddr = "server.org" serverPort = 7000 transport.protocol = "tcp" transport.ConnectServerLocalIP = "one.local.ip" transport.tls.enable = true transport.tls.certFile = "/root/frp_0.60.0_linux_amd64/certs/client.crt" transport.tls.keyFile = "/root/frp_0.60.0_linux_amd64/certs/client.key" transport.tls.trustedCaFile = "/root/frp_0.60.0_linux_amd64/certs/ca.crt" auth.token = "mytoken" [[proxies]] name = "net.11." type = "tcp" localPort = 4433 remotePort = 4433 transport.useEncryption = true ``` Server: ``` bindPort = 7000 quicBindPort = 7000 transport.tls.force = true transport.tls.certFile = "/etc/frp/server.crt" transport.tls.keyFile = "/etc/frp/server.key" transport.tls.trustedCaFile = "/etc/frp/ca.crt" transport.maxPoolCount = 256 auth.method = "token" auth.token = "mytoken" webServer.addr = "127.0.0.1" webServer.port = 7500 ``` ### Logs _No response_ ### Steps to reproduce 1. 2. 3. ... ### Affected area - [X] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [X] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 14:17:37 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:17:41 -06:00

Author

Owner

@fatedier commented on GitHub (Nov 1, 2024):

Simply put, all you need is TLS.

@fatedier commented on GitHub (Nov 1, 2024): Simply put, all you need is TLS.

gitea-mirror commented

2026-05-05 14:17:42 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Nov 23, 2024):

Issues go stale after 21d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (Nov 23, 2024): Issues go stale after 21d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.