Skip to main content

​
DNS & Public Hostname

FRP Auto Deploy separates the server’s Public IP from an optional Public Hostname.

​
Example

Both SSH forms can reach the same published service:
Web examples:

​
Configure the service hostname

Remove it with:
This metadata change does not change CLIENT ID, Service ID, public-port reservations, project CA, or FRP control identity.

​
DNS remains external

FRP Auto Deploy does not call Route53, Cloudflare DNS, DNSZi, or another provider API. Create the DNS record yourself so the hostname resolves to the public entry point.

​
Server behind NAT

If the FRP server is private, the hostname should normally resolve to the firewall/public IP, not the private server address.

​
HTTPS certificate behavior

Published HTTPS is TCP passthrough: FRP Auto Deploy does not issue or replace the published application’s certificate. The target application certificate must be valid for the hostname users enter.

​
Hairpin NAT

Internal clients may fail to reach the public hostname through the firewall’s public IP if the firewall does not support hairpin NAT. Use hairpin NAT or split DNS when needed.
When debugging a hostname problem, first prove the service works by public IP + public port. If IP works and hostname fails, debug DNS/certificate/hairpin behavior before changing FRP state.
Last modified on September 7, 2026