> ## Documentation Index
> Fetch the complete documentation index at: https://frp.xdr.ooo/llms.txt
> Use this file to discover all available pages before exploring further.

# DNS & Public Hostname

> Use a friendly DNS name for published services without changing FRP identity or control-plane semantics.

# DNS & Public Hostname

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

```mermaid theme={null}
flowchart TD
    S[FRP Auto Deploy server]
    IP[Public IP\nInfrastructure/control fallback]
    DNS[Public Hostname\nHuman-friendly service alias]
    S --> IP
    S --> DNS
```

```text theme={null}
Public IP       = primary infrastructure/control reference
Public Hostname = optional user-facing alias for published services
```

## Example

```text theme={null}
Public IP       203.0.113.10
Public Hostname fw.example.com
SSH public port 6000
HTTPS port      6005
```

Both SSH forms can reach the same published service:

```bash theme={null}
ssh -p 6000 user@203.0.113.10
ssh -p 6000 user@fw.example.com
```

Web examples:

```text theme={null}
http://fw.example.com:6004
https://fw.example.com:6005
```

## Configure the service hostname

```bash theme={null}
sudo frpctl set server hostname fw.example.com
```

Remove it with:

```bash theme={null}
sudo frpctl unset server hostname
```

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

## DNS remains external

```mermaid theme={null}
flowchart LR
    D[Your DNS provider] -->|A / AAAA record| P[Public FRP entry point]
    U[User] -->|fw.example.com| D
    P --> S[FRP server or firewall/NAT]
```

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.

```mermaid theme={null}
flowchart LR
    U[User] -->|fw.example.com| F[Public firewall / NAT]
    F -->|DNAT| S[Private FRP server]
```

## HTTPS certificate behavior

Published HTTPS is TCP passthrough:

```mermaid theme={null}
sequenceDiagram
    participant B as Browser
    participant S as FRP server
    participant C as FRP client
    participant W as Target HTTPS app

    B->>S: TLS to fw.example.com:6005
    S->>C: encrypted TCP stream
    C->>W: encrypted TCP stream
    W-->>B: target application's certificate
```

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.

<Tip>
  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.
</Tip>