[GH-ISSUE #610] NGINX HTTPS and FRPS

gitea-mirror commented

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

Owner

Originally created by @keyoti on GitHub (Jan 18, 2018).
Original GitHub issue: https://github.com/fatedier/frp/issues/610

I see two issues #359 and #565 that relate to trying to use NGINX and FRP with SSL. @JaynLau @WordlessEcho @zc57520

It is not working because of this line in nginx config.

proxy_pass https://127.0.0.1:7443;
because (for SSL) FRPS cannot get the hostname (ie subdomain) even with

proxy_set_header Host $host;

The solution is to use the domain name, so that FRPS can identify the correct host.

proxy_pass https://test.example.com:7443;

You will also need to add a resolver in nginx, eg

resolver 8.8.8.8;

Originally created by @keyoti on GitHub (Jan 18, 2018). Original GitHub issue: https://github.com/fatedier/frp/issues/610 I see two issues #359 and #565 that relate to trying to use NGINX and FRP with SSL. @JaynLau @WordlessEcho @zc57520 It is not working because of this line in nginx config. `proxy_pass https://127.0.0.1:7443; ` because (for SSL) FRPS cannot get the hostname (ie subdomain) even with `proxy_set_header Host $host; ` The solution is to use the domain name, so that FRPS can identify the correct host. `proxy_pass https://test.example.com:7443; ` You will also need to add a resolver in nginx, eg `resolver 8.8.8.8; `

gitea-mirror closed this issue

2026-05-05 12:18:23 -06:00

gitea-mirror commented

2026-05-05 12:18:25 -06:00

Author

Owner

@fatedier commented on GitHub (Jan 19, 2018):

Yes, you give the meaningful answer.
Another way to solve this problem is proxy_ssl_server_name.

@fatedier commented on GitHub (Jan 19, 2018): Yes, you give the meaningful answer. Another way to solve this problem is `proxy_ssl_server_name`.

gitea-mirror commented

2026-05-05 12:18:26 -06:00

Author

Owner

@liucodeing commented on GitHub (Feb 27, 2018):

location / {
proxy_pass https://domain.com:7443;
proxy_ssl_server_name on;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
nginx如果使用这种配置是可以正常使用的,
问题解决了, 我还有一个疑问🤔️

我用apache同样提供了一个 https://127.0.0.1:9443 的web服务, nginx配置使用
location / {
proxy_pass https://127.0.0.1:9443;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
完全没有问题,可以正常访问.

frps也是提供了一个https的web服务, 使用相同的nginx配置为什么就不能正常访问呢?
这是否说明 frps的https是存在问题的!

@liucodeing commented on GitHub (Feb 27, 2018): location / { proxy_pass https://domain.com:7443; proxy_ssl_server_name on; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } nginx如果使用这种配置是可以正常使用的, 问题解决了, 我还有一个疑问🤔️ 我用apache同样提供了一个 https://127.0.0.1:9443 的web服务, nginx配置使用 location / { proxy_pass https://127.0.0.1:9443; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } 完全没有问题,可以正常访问. frps也是提供了一个https的web服务, 使用相同的nginx配置为什么就不能正常访问呢? 这是否说明 frps的https是存在问题的!

gitea-mirror commented

2026-05-05 12:18:27 -06:00

Author

Owner

@fatedier commented on GitHub (Feb 27, 2018):

@312102021 建议自行研究下相关的知识。

@fatedier commented on GitHub (Feb 27, 2018): @312102021 建议自行研究下相关的知识。

gitea-mirror commented

2026-05-05 12:18:28 -06:00

Author

Owner

@liucodeing commented on GitHub (Feb 27, 2018):

谢谢!

@liucodeing commented on GitHub (Feb 27, 2018): 谢谢!

gitea-mirror commented

2026-05-05 12:18:28 -06:00

Author

Owner

@wkingfly commented on GitHub (Nov 30, 2018):

其实很大的原因是 ssl 个人证书的问题。有一个相对来说比较简单且可以省掉你大量时间和精力是目前最优雅的解决方案：

去 get 一个 Google 的 .app 域名。为什么呢，因为它强制 https 安全机制，结合 Cloudflare 使用的话证书这些全都不用你去 care，你只需要配置 http 服务即可。
有了 .app 域名，frps 配置 vhost_http_port = 8080，client 端全部按 http 服务来配置，nginx 如下配置即可：

upstream xxx-backend {
    server 127.0.0.1:8080;
}

server {
        listen 80;
        listen [::]:80;

        access_log /var/log/nginx/access.log;

        server_name yourdomain.app;

        location / {
               proxy_set_header X-Real-IP $remote_addr;
               proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
               proxy_set_header Host $http_host;
               proxy_set_header X-NginX-Proxy true;
               proxy_http_version 1.1;
               proxy_set_header Upgrade $http_upgrade;
               proxy_redirect off;
               proxy_set_header        X-Forwarded-Proto $scheme;
               proxy_read_timeout 86400;
               proxy_pass http://xxx-backend/;
        }

frps 和 frpc 之间从 0.25.0 开始支持 TLS 加密，在 frpc.ini 中进行配置。具体配置可从 README 中查看。

@wkingfly commented on GitHub (Nov 30, 2018): 其实很大的原因是 ssl 个人证书的问题。有一个相对来说比较简单且可以省掉你大量时间和精力是目前最优雅的解决方案： 1. 去 get 一个 Google 的 .app 域名。为什么呢，因为它强制 https 安全机制，结合 Cloudflare 使用的话证书这些全都不用你去 care，你只需要配置 http 服务即可。 2. 有了 .app 域名，frps 配置 vhost_http_port = 8080，client 端全部按 http 服务来配置，nginx 如下配置即可： ``` upstream xxx-backend { server 127.0.0.1:8080; } server { listen 80; listen [::]:80; access_log /var/log/nginx/access.log; server_name yourdomain.app; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_redirect off; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 86400; proxy_pass http://xxx-backend/; } ``` 3. frps 和 frpc 之间从 0.25.0 开始支持 TLS 加密，在 frpc.ini 中进行配置。具体配置可从 README 中查看。

gitea-mirror commented

2026-05-05 12:18:29 -06:00

Author

Owner

@hbfrank commented on GitHub (Apr 12, 2019):

其实很大的原因是 ssl 个人证书的问题。有一个相对来说比较简单且可以省掉你大量时间和精力是目前最优雅(graceful)的解决方案：

去 get 一个 Google 的 .app 域名。为什么呢，因为它自带 https，证书这些全都不用你去 care，你只需要配置 http 服务即可。（我这还有一些，如需请联系）

有了 .app 域名，frps 配置 vhost_http_port = 8080，client 端全部按 http 服务来配置，nginx 如下配置即可：
upstream xxx-backend {
    server 127.0.0.1:8080;
}

server {
        listen 80;
        listen [::]:80;

        access_log /var/log/nginx/access.log;

        server_name yourdomain.app;

        location / {
               proxy_set_header X-Real-IP $remote_addr;
               proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
               proxy_set_header Host $http_host;
               proxy_set_header X-NginX-Proxy true;
               proxy_http_version 1.1;
               proxy_set_header Upgrade $http_upgrade;
               proxy_redirect off;
               proxy_set_header        X-Forwarded-Proto $scheme;
               proxy_read_timeout 86400;
               proxy_pass http://xxx-backend/;
        }

这样的话，从frps到client的http就是在裸奔了，前端的https不就失去了意义？

@hbfrank commented on GitHub (Apr 12, 2019): > 其实很大的原因是 ssl 个人证书的问题。有一个相对来说比较简单且可以省掉你大量时间和精力是目前最优雅(graceful)的解决方案： > > 1. 去 get 一个 Google 的 .app 域名。为什么呢，因为它自带 https，证书这些全都不用你去 care，你只需要配置 http 服务即可。（我这还有一些，如需请联系） > 2. 有了 .app 域名，frps 配置 vhost_http_port = 8080，client 端全部按 http 服务来配置，nginx 如下配置即可： > > ``` > upstream xxx-backend { > server 127.0.0.1:8080; > } > > server { > listen 80; > listen [::]:80; > > access_log /var/log/nginx/access.log; > > server_name yourdomain.app; > > location / { > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header Host $http_host; > proxy_set_header X-NginX-Proxy true; > proxy_http_version 1.1; > proxy_set_header Upgrade $http_upgrade; > proxy_redirect off; > proxy_set_header X-Forwarded-Proto $scheme; > proxy_read_timeout 86400; > proxy_pass http://xxx-backend/; > } > ``` 这样的话，从frps到client的http就是在裸奔了，前端的https不就失去了意义？

gitea-mirror commented

2026-05-05 12:18:30 -06:00

Author

Owner

@wkingfly commented on GitHub (Apr 13, 2019):

其实很大的原因是 ssl 个人证书的问题。有一个相对来说比较简单且可以省掉你大量时间和精力是目前最优雅(graceful)的解决方案：

去 get 一个 Google 的 .app 域名。为什么呢，因为它自带 https，证书这些全都不用你去 care，你只需要配置 http 服务即可。（我这还有一些，如需请联系）

有了 .app 域名，frps 配置 vhost_http_port = 8080，client 端全部按 http 服务来配置，nginx 如下配置即可：
upstream xxx-backend {
    server 127.0.0.1:8080;
}

server {
        listen 80;
        listen [::]:80;

        access_log /var/log/nginx/access.log;

        server_name yourdomain.app;

        location / {
               proxy_set_header X-Real-IP $remote_addr;
               proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
               proxy_set_header Host $http_host;
               proxy_set_header X-NginX-Proxy true;
               proxy_http_version 1.1;
               proxy_set_header Upgrade $http_upgrade;
               proxy_redirect off;
               proxy_set_header        X-Forwarded-Proto $scheme;
               proxy_read_timeout 86400;
               proxy_pass http://xxx-backend/;
        }
这样的话，从frps到client的http就是在裸奔了，前端的https不就失去了意义？

多谢提醒，有个参数 use_encryption = false 可保证 frps 到 frpc 之间的通讯是加密的，不过你说的问题是有安全隐患的，目前的更好的解决方案如下：
当前的 README 有一段：

从 v0.25.0 版本开始 frpc 和 frps 之间支持通过 TLS 协议加密传输。通过在 frpc.ini 的 common 中配置 
tls_enable = true 来启用此功能，安全性更高。
为了端口复用，frp 建立 TLS 连接的第一个字节为 0x17。
注意: 启用此功能后除 xtcp 外，不需要再设置 use_encryption。

现在最新版本已经是 0.26.0 , 因此请尽快升级到最新版本并如此设置。另外，仍需要按照我上面的提议来对访问端和 frps 的过程进行加密。

@wkingfly commented on GitHub (Apr 13, 2019): > > 其实很大的原因是 ssl 个人证书的问题。有一个相对来说比较简单且可以省掉你大量时间和精力是目前最优雅(graceful)的解决方案： > > > > 1. 去 get 一个 Google 的 .app 域名。为什么呢，因为它自带 https，证书这些全都不用你去 care，你只需要配置 http 服务即可。（我这还有一些，如需请联系） > > 2. 有了 .app 域名，frps 配置 vhost_http_port = 8080，client 端全部按 http 服务来配置，nginx 如下配置即可： > > > > ``` > > upstream xxx-backend { > > server 127.0.0.1:8080; > > } > > > > server { > > listen 80; > > listen [::]:80; > > > > access_log /var/log/nginx/access.log; > > > > server_name yourdomain.app; > > > > location / { > > proxy_set_header X-Real-IP $remote_addr; > > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > proxy_set_header Host $http_host; > > proxy_set_header X-NginX-Proxy true; > > proxy_http_version 1.1; > > proxy_set_header Upgrade $http_upgrade; > > proxy_redirect off; > > proxy_set_header X-Forwarded-Proto $scheme; > > proxy_read_timeout 86400; > > proxy_pass http://xxx-backend/; > > } > > ``` > > 这样的话，从frps到client的http就是在裸奔了，前端的https不就失去了意义？多谢提醒，有个参数 **use_encryption = false** 可保证 frps 到 frpc 之间的通讯是加密的，不过你说的问题是有安全隐患的，目前的更好的解决方案如下：当前的 README 有一段：从 v0.25.0 版本开始 frpc 和 frps 之间支持通过 TLS 协议加密传输。通过在 frpc.ini 的 common 中配置 tls_enable = true 来启用此功能，安全性更高。为了端口复用，frp 建立 TLS 连接的第一个字节为 0x17。注意: 启用此功能后除 xtcp 外，不需要再设置 use_encryption。现在最新版本已经是 0.26.0 , 因此请尽快升级到最新版本并如此设置。另外，仍需要按照我上面的提议来对访问端和 frps 的过程进行加密。

gitea-mirror commented

2026-05-05 12:18:30 -06:00

Author

Owner

@hbfrank commented on GitHub (Sep 9, 2019):

其实很大的原因是 ssl 个人证书的问题。有一个相对来说比较简单且可以省掉你大量时间和精力是目前最优雅(graceful)的解决方案：

去 get 一个 Google 的 .app 域名。为什么呢，因为它自带 https，证书这些全都不用你去 care，你只需要配置 http 服务即可。（我这还有一些，如需请联系）

有了 .app 域名，frps 配置 vhost_http_port = 8080，client 端全部按 http 服务来配置，nginx 如下配置即可：
upstream xxx-backend {
    server 127.0.0.1:8080;
}

server {
        listen 80;
        listen [::]:80;

        access_log /var/log/nginx/access.log;

        server_name yourdomain.app;

        location / {
               proxy_set_header X-Real-IP $remote_addr;
               proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
               proxy_set_header Host $http_host;
               proxy_set_header X-NginX-Proxy true;
               proxy_http_version 1.1;
               proxy_set_header Upgrade $http_upgrade;
               proxy_redirect off;
               proxy_set_header        X-Forwarded-Proto $scheme;
               proxy_read_timeout 86400;
               proxy_pass http://xxx-backend/;
        }
这样的话，从frps到client的http就是在裸奔了，前端的https不就失去了意义？
多谢提醒，有个参数 use_encryption = false 可保证 frps 到 frpc 之间的通讯是加密的，不过你说的问题是有安全隐患的，目前的更好的解决方案如下：
当前的 README 有一段：
从 v0.25.0 版本开始 frpc 和 frps 之间支持通过 TLS 协议加密传输。通过在 frpc.ini 的 common 中配置 
tls_enable = true 来启用此功能，安全性更高。
为了端口复用，frp 建立 TLS 连接的第一个字节为 0x17。
注意: 启用此功能后除 xtcp 外，不需要再设置 use_encryption。
现在最新版本已经是 0.26.0 , 因此请尽快升级到最新版本并如此设置。另外，仍需要按照我上面的提议来对访问端和 frps 的过程进行加密。

感谢！

@hbfrank commented on GitHub (Sep 9, 2019): > > > 其实很大的原因是 ssl 个人证书的问题。有一个相对来说比较简单且可以省掉你大量时间和精力是目前最优雅(graceful)的解决方案： > > > > > > 1. 去 get 一个 Google 的 .app 域名。为什么呢，因为它自带 https，证书这些全都不用你去 care，你只需要配置 http 服务即可。（我这还有一些，如需请联系） > > > 2. 有了 .app 域名，frps 配置 vhost_http_port = 8080，client 端全部按 http 服务来配置，nginx 如下配置即可： > > > > > > ``` > > > upstream xxx-backend { > > > server 127.0.0.1:8080; > > > } > > > > > > server { > > > listen 80; > > > listen [::]:80; > > > > > > access_log /var/log/nginx/access.log; > > > > > > server_name yourdomain.app; > > > > > > location / { > > > proxy_set_header X-Real-IP $remote_addr; > > > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > > proxy_set_header Host $http_host; > > > proxy_set_header X-NginX-Proxy true; > > > proxy_http_version 1.1; > > > proxy_set_header Upgrade $http_upgrade; > > > proxy_redirect off; > > > proxy_set_header X-Forwarded-Proto $scheme; > > > proxy_read_timeout 86400; > > > proxy_pass http://xxx-backend/; > > > } > > > ``` > > > > > > 这样的话，从frps到client的http就是在裸奔了，前端的https不就失去了意义？ > > 多谢提醒，有个参数 **use_encryption = false** 可保证 frps 到 frpc 之间的通讯是加密的，不过你说的问题是有安全隐患的，目前的更好的解决方案如下： > 当前的 README 有一段： > > ``` > 从 v0.25.0 版本开始 frpc 和 frps 之间支持通过 TLS 协议加密传输。通过在 frpc.ini 的 common 中配置 > tls_enable = true 来启用此功能，安全性更高。 > 为了端口复用，frp 建立 TLS 连接的第一个字节为 0x17。 > 注意: 启用此功能后除 xtcp 外，不需要再设置 use_encryption。 > ``` > > 现在最新版本已经是 0.26.0 , 因此请尽快升级到最新版本并如此设置。另外，仍需要按照我上面的提议来对访问端和 frps 的过程进行加密。感谢！

Rows
Columns

[GH-ISSUE #610] NGINX HTTPS and FRPS #474