github-starred/frp

Fork 0

mirror of https://github.com/fatedier/frp.git synced 2026-05-15 16:15:49 -06:00

[GH-ISSUE #4538] TLS setup #3586

New issue

Closed

opened 2026-05-05 14:18:16 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 14:18:16 -06:00

Owner

Originally created by @PeterBasista on GitHub (Nov 15, 2024).
Original GitHub issue: https://github.com/fatedier/frp/issues/4538

Bug Description

Hi everyone,

I’m seeking assistance with generating certificates for my frps and frpc setup. Although I’ve followed the documentation closely, I’m running into issues.

Here’s a brief overview of my setup:

Public Server: Has a static IP and FQDN
Private Home Server

Currently, without TLS enabled, I can successfully connect to my private home server using subdomains like anything.custom.domain.com or new.domain.com

However, problems arise when I try to add certificates to the server and client. I’ve been following the documentation and here’s the code I’ve been using to generate the certificates (redacted for clarity):

my-openssl.cnf

[ ca ]
default_ca = CA_default
[ CA_default ]
x509_extensions = usr_cert
[ req ]
default_bits        = 2048
default_md          = sha256
default_keyfile     = privkey.pem
distinguished_name  = req_distinguished_name
attributes          = req_attributes
x509_extensions     = v3_ca
string_mask         = utf8only
[ req_distinguished_name ]
[ req_attributes ]
[ usr_cert ]
basicConstraints       = CA:FALSE
nsComment              = "OpenSSL Generated Certificate"
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer
[ v3_ca ]
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints       = CA:true

certs generation

openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -subj "/CN=domain.com CA" -days 5000 -out ca.crt

openssl genrsa -out server.key 2048

openssl req -new -sha256 -key server.key \
    -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=domain.com" \
    -reqexts SAN \
    -config <(cat my-openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:domain.com,IP:40.11.11.111,DNS:*.domain.com")) \
    -out server.csr

openssl x509 -req -days 5000 -sha256 \
    -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
    -extfile <(printf "subjectAltName=DNS:domain.com,IP:40.11.11.111,DNS:*.domain.com") \
    -out server.crt

openssl genrsa -out client.key 2048

openssl req -new -sha256 -key client.key \
    -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=domain.com" \
    -reqexts SAN \
    -config <(cat my-openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:domain.com,DNS:*.domain.com")) \
    -out client.csr

openssl x509 -req -days 5000 -sha256 \
    -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
    -extfile <(printf "subjectAltName=DNS:domain.com,DNS:*.domain.com") \
    -out client.crt

I need to ensure that all connections for *.custom.domain.com or new.domain.com will be routed to the home server.

Best regards,
Peter

frpc Version

0.61.0

frps Version

0.61.0

System Architecture

linux/amd64

Configurations

frps.toml

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

bindPort = 7000
vhostHTTPPort = 7000
vhostHTTPSPort = 7000
auth.method = "token"
auth.token = "*********************"  
allowPorts = [
  { single = 80 },
  { single = 443 }
]

frpc.toml

transport.tls.enable = true
transport.tls.certFile = "/etc/frp/certs/client.crt"
transport.tls.keyFile = "/etc/frp/certs/client.key"
transport.tls.trustedCaFile = "/etc/frp/certs/ca.crt"

serverAddr = "40.11.11.111"
serverPort = 7000
auth.method = "token"
auth.token = "*************"

[[proxies]]
name = "Nginx HTTP"
type = "http"
localIP = "192.168.31.100"
localPort = 80
customDomains = ["*.custom.domain.com", "new.domain.com"]

[[proxies]]
name = "Nginx HTTPS"
type = "https"
localIp = "192.168.31.100"
localPort = 443
customDomains = ["*.custom.domain.com", "new.domain.com"]

Logs

2024-11-15 06:50:07.406 [I] [sub/root.go:142] start frpc service for config file [/etc/frp/frpc.toml]
2024-11-15 06:50:07.406 [I] [client/service.go:295] try to connect to server...
2024-11-15 06:50:07.458 [W] [client/service.go:298] connect to server error: remote error: tls: unrecognized name
2024-11-15 06:50:07.458 [I] [sub/root.go:160] frpc service for config file [/etc/frp/frpc.toml] stopped
login to the server failed: remote error: tls: unrecognized name. With loginFailExit enabled, no additional retries will be attempted

Steps to reproduce

setup FRPS and FRPC without TLS
test connectivity
generate certificates
setup TLS in configuration files
test connectivity

Affected area

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

Originally created by @PeterBasista on GitHub (Nov 15, 2024). Original GitHub issue: https://github.com/fatedier/frp/issues/4538 ### Bug Description Hi everyone, I’m seeking assistance with generating certificates for my `frps` and `frpc` setup. Although I’ve followed the documentation closely, I’m running into issues. Here’s a brief overview of my setup: - Public Server: Has a static IP and FQDN - Private Home Server Currently, without TLS enabled, I can successfully connect to my private home server using subdomains like anything.custom.domain.com or new.domain.com However, problems arise when I try to add certificates to the server and client. I’ve been following the documentation and here’s the code I’ve been using to generate the certificates (redacted for clarity): _my-openssl.cnf_ ``` [ ca ] default_ca = CA_default [ CA_default ] x509_extensions = usr_cert [ req ] default_bits = 2048 default_md = sha256 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca string_mask = utf8only [ req_distinguished_name ] [ req_attributes ] [ usr_cert ] basicConstraints = CA:FALSE nsComment = "OpenSSL Generated Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer [ v3_ca ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = CA:true ``` _certs generation_ ``` openssl genrsa -out ca.key 2048 openssl req -x509 -new -nodes -key ca.key -subj "/CN=domain.com CA" -days 5000 -out ca.crt openssl genrsa -out server.key 2048 openssl req -new -sha256 -key server.key \ -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=domain.com" \ -reqexts SAN \ -config <(cat my-openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:domain.com,IP:40.11.11.111,DNS:*.domain.com")) \ -out server.csr openssl x509 -req -days 5000 -sha256 \ -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -extfile <(printf "subjectAltName=DNS:domain.com,IP:40.11.11.111,DNS:*.domain.com") \ -out server.crt openssl genrsa -out client.key 2048 openssl req -new -sha256 -key client.key \ -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=domain.com" \ -reqexts SAN \ -config <(cat my-openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:domain.com,DNS:*.domain.com")) \ -out client.csr openssl x509 -req -days 5000 -sha256 \ -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -extfile <(printf "subjectAltName=DNS:domain.com,DNS:*.domain.com") \ -out client.crt ``` I need to ensure that all connections for *.custom.domain.com or new.domain.com will be routed to the home server. Best regards, Peter ### frpc Version 0.61.0 ### frps Version 0.61.0 ### System Architecture linux/amd64 ### Configurations # frps.toml ``` transport.tls.force = true transport.tls.certFile = "/etc/frp/certs/server.crt" transport.tls.keyFile = "/etc/frp/certs/server.key" transport.tls.trustedCaFile = "/etc/frp/certs/ca.crt" bindPort = 7000 vhostHTTPPort = 7000 vhostHTTPSPort = 7000 auth.method = "token" auth.token = "*********************" allowPorts = [ { single = 80 }, { single = 443 } ] ``` # frpc.toml ``` transport.tls.enable = true transport.tls.certFile = "/etc/frp/certs/client.crt" transport.tls.keyFile = "/etc/frp/certs/client.key" transport.tls.trustedCaFile = "/etc/frp/certs/ca.crt" serverAddr = "40.11.11.111" serverPort = 7000 auth.method = "token" auth.token = "*************" [[proxies]] name = "Nginx HTTP" type = "http" localIP = "192.168.31.100" localPort = 80 customDomains = ["*.custom.domain.com", "new.domain.com"] [[proxies]] name = "Nginx HTTPS" type = "https" localIp = "192.168.31.100" localPort = 443 customDomains = ["*.custom.domain.com", "new.domain.com"] ``` ### Logs ``` 2024-11-15 06:50:07.406 [I] [sub/root.go:142] start frpc service for config file [/etc/frp/frpc.toml] 2024-11-15 06:50:07.406 [I] [client/service.go:295] try to connect to server... 2024-11-15 06:50:07.458 [W] [client/service.go:298] connect to server error: remote error: tls: unrecognized name 2024-11-15 06:50:07.458 [I] [sub/root.go:160] frpc service for config file [/etc/frp/frpc.toml] stopped login to the server failed: remote error: tls: unrecognized name. With loginFailExit enabled, no additional retries will be attempted ``` ### Steps to reproduce 1. setup FRPS and FRPC without TLS 2. test connectivity 3. generate certificates 4. setup TLS in configuration files 5. test connectivity ### Affected area - [X] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror closed this issue

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

gitea-mirror commented

2026-05-05 14:18:19 -06:00

Author

Owner

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

I asked ChatGPT about the possible reasons:

The issue you're experiencing stems from a mismatch between the Server Name Indication (SNI) sent by the frpc client and the names recognized by the frps server's TLS certificate. Specifically, the error message:
connect to server error: remote error: tls: unrecognized name
indicates that the server does not recognize the SNI provided by the client during the TLS handshake.

Root Cause

When frpc connects to frps, it uses the serverAddr (40.11.11.111) as the default SNI. However, IP addresses are generally not supported as SNI values in TLS handshakes—they are meant to be domain names. Moreover, even though your server's certificate includes IP:40.11.11.111 in the subjectAltName, the SNI is expected to be a DNS name, not an IP address.

This mismatch causes the TLS handshake to fail because the server's certificate does not recognize the SNI (which is the IP address in this case).

Solution

To resolve this issue, you need to explicitly set the transport.tls.serverName in your frpc.toml configuration file to match one of the domain names specified in your server's TLS certificate (e.g., domain.com).

Steps to Fix:
Edit your frpc.toml configuration file:

Add the following line under your transport.tls settings:
transport.tls.serverName = "domain.com"
This explicitly sets the SNI to domain.com, which matches the Common Name (CN) and subjectAltName in your server's certificate.
Ensure your server's certificate covers the SNI:

Your server's certificate should already include domain.com and *.domain.com in the subjectAltName. If not, regenerate your server's certificate to include these names.

Restart frpc and frps:

After making the changes, restart both the client and server to apply the new configurations.
Updated frpc.toml Configuration:
transport.tls.enable = true
transport.tls.certFile = "/etc/frp/certs/client.crt"
transport.tls.keyFile = "/etc/frp/certs/client.key"
transport.tls.trustedCaFile = "/etc/frp/certs/ca.crt"
transport.tls.serverName = "domain.com"  # Added line

serverAddr = "40.11.11.111"
serverPort = 7000
auth.method = "token"
auth.token = "*************"

[[proxies]]
name = "Nginx HTTP"
type = "http"
localIP = "192.168.31.100"
localPort = 80
customDomains = ["*.custom.domain.com", "new.domain.com"]

[[proxies]]
name = "Nginx HTTPS"
type = "https"
localIp = "192.168.31.100"
localPort = 443
customDomains = ["*.custom.domain.com", "new.domain.com"]
Additional Considerations

Port Configurations:

Ensure that vhostHTTPPort and vhostHTTPSPort in your frps.toml are set to appropriate values and not conflicting with bindPort. They typically should be different ports.

Certificate Validity:

Double-check that your certificates are correctly generated and valid. The subjectAltName should include all domain names and IP addresses that clients might use to connect.

DNS Resolution:

If possible, use a domain name instead of an IP address for serverAddr to avoid issues with IP-based SNI.

Explanation

By setting transport.tls.serverName to "domain.com", you ensure that the SNI sent by the frpc client matches one of the domain names in your server's TLS certificate. This alignment allows the TLS handshake to succeed because the server recognizes the SNI and can present the appropriate certificate.

References

FRP Documentation on TLS Configuration:

The transport.tls.serverName parameter specifies the SNI sent by frpc. If not set, it defaults to serverAddr, which in your case is an IP address.

TLS and SNI:

SNI is designed to carry a hostname, not an IP address. Servers use the SNI to select the correct certificate to present to the client.

Conclusion

By explicitly specifying the transport.tls.serverName in your frpc configuration to match the domain name in your server's certificate, you resolve the SNI mismatch causing the TLS handshake failure.

Note: Always ensure that your configurations and certificates are securely managed and that sensitive information like tokens and private keys are properly protected.

@fatedier commented on GitHub (Nov 15, 2024): I asked ChatGPT about the possible reasons: > The issue you're experiencing stems from a mismatch between the Server Name Indication (SNI) sent by the `frpc` client and the names recognized by the `frps` server's TLS certificate. Specifically, the error message: > > ``` > connect to server error: remote error: tls: unrecognized name > ``` > > indicates that the server does not recognize the SNI provided by the client during the TLS handshake. > > ### Root Cause > > When `frpc` connects to `frps`, it uses the `serverAddr` (`40.11.11.111`) as the default SNI. However, IP addresses are generally not supported as SNI values in TLS handshakes—they are meant to be domain names. Moreover, even though your server's certificate includes `IP:40.11.11.111` in the `subjectAltName`, the SNI is expected to be a DNS name, not an IP address. > > This mismatch causes the TLS handshake to fail because the server's certificate does not recognize the SNI (which is the IP address in this case). > > ### Solution > > To resolve this issue, you need to explicitly set the `transport.tls.serverName` in your `frpc.toml` configuration file to match one of the domain names specified in your server's TLS certificate (e.g., `domain.com`). > > #### Steps to Fix: > > 1. **Edit your `frpc.toml` configuration file:** > > Add the following line under your `transport.tls` settings: > > ```toml > transport.tls.serverName = "domain.com" > ``` > > This explicitly sets the SNI to `domain.com`, which matches the `Common Name` (`CN`) and `subjectAltName` in your server's certificate. > > 2. **Ensure your server's certificate covers the SNI:** > > Your server's certificate should already include `domain.com` and `*.domain.com` in the `subjectAltName`. If not, regenerate your server's certificate to include these names. > > 3. **Restart `frpc` and `frps`:** > > After making the changes, restart both the client and server to apply the new configurations. > > #### Updated `frpc.toml` Configuration: > > ```toml > transport.tls.enable = true > transport.tls.certFile = "/etc/frp/certs/client.crt" > transport.tls.keyFile = "/etc/frp/certs/client.key" > transport.tls.trustedCaFile = "/etc/frp/certs/ca.crt" > transport.tls.serverName = "domain.com" # Added line > > serverAddr = "40.11.11.111" > serverPort = 7000 > auth.method = "token" > auth.token = "*************" > > [[proxies]] > name = "Nginx HTTP" > type = "http" > localIP = "192.168.31.100" > localPort = 80 > customDomains = ["*.custom.domain.com", "new.domain.com"] > > [[proxies]] > name = "Nginx HTTPS" > type = "https" > localIp = "192.168.31.100" > localPort = 443 > customDomains = ["*.custom.domain.com", "new.domain.com"] > ``` > > ### Additional Considerations > > - **Port Configurations:** > > Ensure that `vhostHTTPPort` and `vhostHTTPSPort` in your `frps.toml` are set to appropriate values and not conflicting with `bindPort`. They typically should be different ports. > > - **Certificate Validity:** > > Double-check that your certificates are correctly generated and valid. The `subjectAltName` should include all domain names and IP addresses that clients might use to connect. > > - **DNS Resolution:** > > If possible, use a domain name instead of an IP address for `serverAddr` to avoid issues with IP-based SNI. > > ### Explanation > > By setting `transport.tls.serverName` to `"domain.com"`, you ensure that the SNI sent by the `frpc` client matches one of the domain names in your server's TLS certificate. This alignment allows the TLS handshake to succeed because the server recognizes the SNI and can present the appropriate certificate. > > ### References > > - **FRP Documentation on TLS Configuration:** > > The `transport.tls.serverName` parameter specifies the SNI sent by `frpc`. If not set, it defaults to `serverAddr`, which in your case is an IP address. > > - **TLS and SNI:** > > SNI is designed to carry a hostname, not an IP address. Servers use the SNI to select the correct certificate to present to the client. > > ### Conclusion > > By explicitly specifying the `transport.tls.serverName` in your `frpc` configuration to match the domain name in your server's certificate, you resolve the SNI mismatch causing the TLS handshake failure. > > --- > > **Note:** Always ensure that your configurations and certificates are securely managed and that sensitive information like tokens and private keys are properly protected.

gitea-mirror commented

2026-05-05 14:18:20 -06:00

Author

Owner

@PeterBasista commented on GitHub (Nov 15, 2024):

Thanks for you reply (and also thank to ChatGPT).

I applied all the changes which has been generated by ChatGPT.

I removed all IPs from cert generating and regenerated the certs
Added transport.tls.serverName
(also adjusted serverAddr and tried with and without but results are same)

After restart I have still same problems:

2024-11-15 08:23:54.713 [I] [sub/root.go:142] start frpc service for config file [/etc/frp/frpc.toml]
2024-11-15 08:23:54.714 [I] [client/service.go:295] try to connect to server...
2024-11-15 08:23:54.801 [W] [client/service.go:298] connect to server error: remote error: tls: unrecognized name
2024-11-15 08:23:54.801 [I] [sub/root.go:160] frpc service for config file [/etc/frp/frpc.toml] stopped
login to the server failed: remote error: tls: unrecognized name. With loginFailExit enabled, no additional retries will be attempted

I have no idea what I am doing wrong, really, I also tried to ask copilot as I do not have chatGPT but nothing really helpful.

openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -subj "/CN=domain.com CA" -days 5000 -out ca.crt

openssl genrsa -out server.key 2048
openssl req -new -sha256 -key server.key \
    -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=domain.com" \
    -reqexts SAN \
    -config <(cat my-openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:domain.com,DNS:*.domain.com")) \
    -out server.csr

openssl x509 -req -days 5000 -sha256 \
    -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
    -extfile <(printf "subjectAltName=DNS:domain.com,DNS:*.domain.com") \
    -out server.crt

openssl genrsa -out client.key 2048
openssl req -new -sha256 -key client.key \
    -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=domain.com" \
    -reqexts SAN \
    -config <(cat my-openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:domain.com,DNS:*.domain.com")) \
    -out client.csr

openssl x509 -req -days 5000 -sha256 \
    -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
    -extfile <(printf "subjectAltName=DNS:domain.com,DNS:*.domain.com") \
    -out client.crt

frps.toml

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

bindPort = 7000
vhostHTTPPort = 7000
vhostHTTPSPort = 7000
auth.method = "token"
auth.token = "*********************"  
allowPorts = [
  { single = 80 },
  { single = 443 }
]

frpc.toml

transport.tls.enable = true
transport.tls.certFile = "/etc/frp/certs/client.crt"
transport.tls.keyFile = "/etc/frp/certs/client.key"
transport.tls.trustedCaFile = "/etc/frp/certs/ca.crt"
transport.tls.serverName = "domain.com"

serverAddr = "domain.com"
serverPort = 7000
auth.method = "token"
auth.token = "*************"

[[proxies]]
name = "Nginx HTTP"
type = "http"
localIP = "192.168.31.100"
localPort = 80
customDomains = ["*.custom.domain.com", "new.domain.com"]

[[proxies]]
name = "Nginx HTTPS"
type = "https"
localIp = "192.168.31.100"
localPort = 443
customDomains = ["*.custom.domain.com", "new.domain.com"]

@PeterBasista commented on GitHub (Nov 15, 2024): Thanks for you reply (and also thank to ChatGPT). I applied all the changes which has been generated by ChatGPT. - I removed all IPs from cert generating and regenerated the certs - Added `transport.tls.serverName` - (also adjusted serverAddr and tried with and without but results are same) After restart I have still same problems: ``` 2024-11-15 08:23:54.713 [I] [sub/root.go:142] start frpc service for config file [/etc/frp/frpc.toml] 2024-11-15 08:23:54.714 [I] [client/service.go:295] try to connect to server... 2024-11-15 08:23:54.801 [W] [client/service.go:298] connect to server error: remote error: tls: unrecognized name 2024-11-15 08:23:54.801 [I] [sub/root.go:160] frpc service for config file [/etc/frp/frpc.toml] stopped login to the server failed: remote error: tls: unrecognized name. With loginFailExit enabled, no additional retries will be attempted ``` I have no idea what I am doing wrong, really, I also tried to ask copilot as I do not have chatGPT but nothing really helpful. ``` openssl genrsa -out ca.key 2048 openssl req -x509 -new -nodes -key ca.key -subj "/CN=domain.com CA" -days 5000 -out ca.crt openssl genrsa -out server.key 2048 openssl req -new -sha256 -key server.key \ -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=domain.com" \ -reqexts SAN \ -config <(cat my-openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:domain.com,DNS:*.domain.com")) \ -out server.csr openssl x509 -req -days 5000 -sha256 \ -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -extfile <(printf "subjectAltName=DNS:domain.com,DNS:*.domain.com") \ -out server.crt openssl genrsa -out client.key 2048 openssl req -new -sha256 -key client.key \ -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=domain.com" \ -reqexts SAN \ -config <(cat my-openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:domain.com,DNS:*.domain.com")) \ -out client.csr openssl x509 -req -days 5000 -sha256 \ -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -extfile <(printf "subjectAltName=DNS:domain.com,DNS:*.domain.com") \ -out client.crt ``` # frps.toml ``` transport.tls.force = true transport.tls.certFile = "/etc/frp/certs/server.crt" transport.tls.keyFile = "/etc/frp/certs/server.key" transport.tls.trustedCaFile = "/etc/frp/certs/ca.crt" bindPort = 7000 vhostHTTPPort = 7000 vhostHTTPSPort = 7000 auth.method = "token" auth.token = "*********************" allowPorts = [ { single = 80 }, { single = 443 } ] ``` # frpc.toml ``` transport.tls.enable = true transport.tls.certFile = "/etc/frp/certs/client.crt" transport.tls.keyFile = "/etc/frp/certs/client.key" transport.tls.trustedCaFile = "/etc/frp/certs/ca.crt" transport.tls.serverName = "domain.com" serverAddr = "domain.com" serverPort = 7000 auth.method = "token" auth.token = "*************" [[proxies]] name = "Nginx HTTP" type = "http" localIP = "192.168.31.100" localPort = 80 customDomains = ["*.custom.domain.com", "new.domain.com"] [[proxies]] name = "Nginx HTTPS" type = "https" localIp = "192.168.31.100" localPort = 443 customDomains = ["*.custom.domain.com", "new.domain.com"] ```

gitea-mirror commented

2026-05-05 14:18:21 -06:00

Author

Owner

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

bindPort = 7000
vhostHTTPPort = 7000
vhostHTTPSPort = 7000

Perhaps it's an issue here; in this case, bindPort cannot be the same as vhostHTTPSPort.

@fatedier commented on GitHub (Nov 15, 2024): ``` bindPort = 7000 vhostHTTPPort = 7000 vhostHTTPSPort = 7000 ``` Perhaps it's an issue here; in this case, bindPort cannot be the same as vhostHTTPSPort.

gitea-mirror commented

2026-05-05 14:18:22 -06:00

Author

Owner

@PeterBasista commented on GitHub (Nov 15, 2024):

Okay, you were right. I needed also adjust apache2 conf for correct ports but now everything is working as expected! Thank you very much for you help. I really appreciate it that you helped me to better understand configuration part of this project. Thank you for helping me secure my FRP instances.

What I needed to do:

bindPort = 7000
vhostHTTPPort = 8080
vhostHTTPSPort = 8443

and then change in the apache2 available sites configuration to:

# HTTP
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/

# HTTPS
ProxyPass / https://localhost:8443/
ProxyPassReverse / https://localhost:8443/

@PeterBasista commented on GitHub (Nov 15, 2024): Okay, you were right. I needed also adjust apache2 conf for correct ports but now everything is working as expected! Thank you very much for you help. I really appreciate it that you helped me to better understand configuration part of this project. Thank you for helping me secure my FRP instances. What I needed to do: ``` bindPort = 7000 vhostHTTPPort = 8080 vhostHTTPSPort = 8443 ``` and then change in the apache2 available sites configuration to: ``` # HTTP ProxyPass / http://localhost:8080/ ProxyPassReverse / http://localhost:8080/ # HTTPS ProxyPass / https://localhost:8443/ ProxyPassReverse / https://localhost:8443/ ```