Tell me how to Switch to WireGuard - Tailscale

I have Arch Linux on Hostinger. Can I proxy and serve Apache Web pages from my home?


Gemini

Yes, you can absolutely use your Arch Linux VPS on Hostinger to reverse-proxy traffic and serve Apache web pages hosted on your home server.

Since home internet connections typically lack a static public IPv4 address or sit behind CGNAT (Carrier-Grade NAT), the standard approach is to establish a secure tunnel between your home web server and your Hostinger VPS, then configure Apache (or Nginx) on the VPS to forward incoming requests through that tunnel.

Core Architecture Options

Method How It Works Best Used For
WireGuard / Tailscale Subnet Routing Creates a lightweight mesh network/VPN between VPS and home. VPS proxies traffic over internal VPN IP. Best overall balance of speed, low overhead, and security.
SSH Reverse Tunnel (autossh) Home machine initiates an encrypted SSH remote port forward back to the VPS. Minimal dependencies, setup in minutes without extra network drivers.
Cloudflare Tunnel (cloudflared) Traffic flows through Cloudflare directly to your home Apache without needing a public VPS IP mapping, though Hostinger can still act as an intermediary if needed. If you want built-in DDoS protection and no open ports.

Setup Guide (Using WireGuard + Apache Reverse Proxy)

Below is the standard, most reliable method using WireGuard to create a private tunnel between Hostinger and your home machine, and Apache on Hostinger to reverse proxy domain traffic.

Step 1: Establish the Tunnel (WireGuard)

  1. VPS (Hostinger - WireGuard Server): Install WireGuard and generate key pairs:
    sudo pacman -S wireguard-tools
    wg genkey | tee vps_private.key | wg pubkey > vps_public.key
    
    Create /etc/wireguard/wg0.conf:
    [Interface]
    PrivateKey = <VPS_PRIVATE_KEY>
    Address = 10.0.0.1/24
    ListenPort = 51820
    
    Start the service: sudo systemctl enable --now wg-quick@wg0
  2. Home Server (Client): Install WireGuard, generate key pairs (home_private.key / home_public.key), and create /etc/wireguard/wg0.conf:
    [Interface]
    PrivateKey = <HOME_PRIVATE_KEY>
    Address = 10.0.0.2/24
    [Peer]
    PublicKey = <VPS_PUBLIC_KEY>
    Endpoint = <HOSTINGER_VPS_PUBLIC_IP>:51820
    AllowedIPs = 10.0.0.0/24
    PersistentKeepalive = 25
    
    Note: PersistentKeepalive = 25 ensures the tunnel stays open through home routers/NATs.
  3. Add Home Peer to VPS: On the VPS, append the home client details to /etc/wireguard/wg0.conf:
    [Peer]
    PublicKey = <HOME_PUBLIC_KEY>
    AllowedIPs = 10.0.0.2/32
    
    Restart the interface on the VPS (sudo systemctl restart wg-quick@wg0) and start it at home (sudo systemctl enable --now wg-quick@wg0). Verify connectivity by pinging 10.0.0.2 from the VPS.

Step 2: Configure Apache Reverse Proxy on Hostinger VPS

  1. Ensure the required proxy modules are enabled in your Apache configuration (/etc/httpd/conf/httpd.conf on Arch Linux):
    Atlantic.Net
    LoadModule proxy_module modules/mod_proxy.so
    LoadModule proxy_http_module modules/mod_proxy_http.so
    
  2. Add a virtual host configuration on your VPS pointing to the home server's internal tunnel IP (10.0.0.2):
    <VirtualHost *:80>
        ServerName yourdomain.com
        ProxyPreserveHost On
        ProxyPass / http://10.0.0.2:80/
        ProxyPassReverse / http://10.0.0.2:80/
        ErrorLog "/var/log/httpd/yourdomain-error.log"
        CustomLog "/var/log/httpd/yourdomain-access.log" common
    </VirtualHost>
    
  3. Test and reload Apache on Hostinger:
    sudo apachectl configtest
    sudo systemctl restart httpd
    

Step 3: SSL / TLS Termination

You can terminate SSL/TLS right on the Hostinger VPS using Certbot:

sudo pacman -S certbot certbot-apache
sudo certbot --apache -d yourdomain.com

This manages HTTPS automatically at the VPS level while sending clean HTTP traffic over the encrypted WireGuard tunnel to your home server.

Alternative: Quick SSH Reverse Tunnel (autossh)

If you prefer not to configure a full VPN network, you can forward traffic using an SSH reverse tunnel directly from your home machine:

  1. On your home machine, run:
    autossh -M 0 -N -R 8080:localhost:80 user@HOSTINGER_VPS_IP
    
  2. On your Hostinger VPS, point your Apache ProxyPass to [http://127.0.0.1:8080/](http://127.0.0.1:8080/).

You

How do I set up a persistent SSH reverse tunnel using autossh and systemd to proxy traffic from Hostinger to home?


Gemini

Setting up a persistent SSH reverse tunnel with autossh managed by systemd gives you a resilient connection that automatically reconnects after network drops or server reboots.

Here is the step-by-step procedure to establish the tunnel from your home server to your Hostinger VPS.

Step 1: Prepare SSH Key Authentication

The home server needs to authenticate to the Hostinger VPS using an SSH key without requiring a password.

  1. On your Home Server, generate a dedicated SSH key pair if you don't already have one:
    ssh-keygen -t ed25519 -f ~/.ssh/id_vps_tunnel -N ""
    
  2. Copy the public key to your Hostinger VPS:
    ssh-copy-id -i ~/.ssh/id_vps_tunnel.pub user@HOSTINGER_VPS_IP
    
    (Replace user and HOSTINGER_VPS_IP with your actual username and Hostinger VPS IP address).
  3. Test the connection manually from your home server to confirm it connects without prompting for a password:
    ssh -i ~/.ssh/id_vps_tunnel user@HOSTINGER_VPS_IP
    

Step 2: Test the Reverse Tunnel Command

Verify the exact tunnel command works before wrapping it into a service.

Run this command on your Home Server:

autossh -M 0 -N -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -o "ExitOnForwardFailure yes" -i ~/.ssh/id_vps_tunnel -R 8080:localhost:80 user@HOSTINGER_VPS_IP
  • -M 0: Disables autossh 's legacy monitoring port and lets SSH's built-in ServerAlive keep-alives manage connection monitoring.
  • -N: Tells SSH not to execute a remote command (tunnel only).
  • -R 8080:localhost:80: Forwards port 8080 on the Hostinger VPS back to port 80 (your Apache web server) on your home machine.
  • ExitOnForwardFailure yes: Forces SSH to exit immediately if the port binding fails, allowing autossh / systemd to recognize the failure and trigger a restart.

To verify: On your Hostinger VPS, run curl [http://127.0.0.1:8080](http://127.0.0.1:8080). You should receive the HTTP response from your home Apache server.

Step 3: Create the Systemd Service

To keep this tunnel alive indefinitely and across system reboots, create a systemd service on your Home Server.

  1. Create a new service file:
    sudo nano /etc/systemd/system/vps-tunnel.service
    
  2. Add the following configuration (update the username, key path, and VPS IP):
    [Unit]
    Description=AutoSSH Reverse Tunnel to Hostinger VPS
    After=network-online.target
    Wants=network-online.target
    [Service]
    Type=simple
    User=YOUR_HOME_USERNAME
    Environment="AUTOSSH_GATETIME=0"
    ExecStart=/usr/bin/autossh -M 0 -N \
        -o "ServerAliveInterval 30" \
        -o "ServerAliveCountMax 3" \
        -o "ExitOnForwardFailure yes" \
        -o "StrictHostKeyChecking=accept-new" \
        -i /home/YOUR_HOME_USERNAME/.ssh/id_vps_tunnel \
        -R 8080:localhost:80 \
        YOUR_VPS_USERNAME@HOSTINGER_VPS_IP
    Restart=always
    RestartSec=10
    [Install]
    WantedBy=multi-user.target
    
    Note: AUTOSSH_GATETIME=0 ensures autossh immediately retries establishing the connection even if the network is down when the service starts.

Step 4: Enable and Start the Service

  1. Reload systemd to pick up the new unit file:
    sudo systemctl daemon-reload
    
  2. Enable the service to launch automatically at boot and start it now:
    sudo systemctl enable --now vps-tunnel.service
    
  3. Check the service status:
    sudo systemctl status vps-tunnel.service
    
  4. Check the logs if you need to debug connection attempts:
    journalctl -u vps-tunnel.service -f
    

Step 5: Configure Apache Proxy on Hostinger VPS

On your Hostinger Arch Linux VPS, point your VirtualHost block to the local end of the tunnel (127.0.0.1:8080):

<VirtualHost *:80>
    ServerName yourdomain.com

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/

    ErrorLog "/var/log/httpd/yourdomain-error.log"
    CustomLog "/var/log/httpd/yourdomain-access.log" common
</VirtualHost>

Restart Apache on Hostinger to apply:

sudo systemctl restart httpd

How is your Apache virtual host setup on Hostinger coming along?


You

Then my home pages would be served on port 8080?


Gemini

No, your visitors will still access your home web pages on standard web ports (port 80 for HTTP or port 443 for HTTPS) using your domain name in their browser.

Port 8080 is only used internally on the Hostinger VPS as a local loopback bridge between Apache and the SSH tunnel.

How the Flow Works

Public User
    │
    │  1. Requests http://yourdomain.com (Port 80)
    ▼
Hostinger VPS (Apache Reverse Proxy)
    │
    │  2. Translates request to internal loopback (127.0.0.1:8080)
    ▼
SSH Tunnel (Listening on VPS Port 8080)
    │
    │  3. Encrypted transit through the tunnel
    ▼
Home Server (Apache listening on Port 80)
  1. The Public Side (Ports 80 / 443): When a user visits [http://yourdomain.com](http://yourdomain.com), they connect to your Hostinger VPS on port 80 (or 443 for HTTPS).
  2. The Proxy (Port 8080): Apache on Hostinger receives the request and forwards it internally to 127.0.0.1:8080.
  3. The SSH Tunnel: autossh is listening on port 8080 only on the VPS's internal loopback interface. It catches that traffic and routes it through the encrypted tunnel to your home machine.
  4. Your Home Server (Port 80): The tunnel delivers the traffic to your home machine's local Apache instance, which processes the request on standard port 80 and sends the webpage back through the same pipeline.

Key Takeaways

  • No Port in URL: Visitors never type :8080 in their browser. They just use yourdomain.com.
  • Home Port Unchanged: Your home Apache server continues running on its standard web port (80/443).
  • Port 8080 is Private: Port 8080 on the Hostinger VPS does not need to be opened in your firewall (ufw or iptables) to the outside world—it is only accessed locally by Apache via 127.0.0.1.

Want to set up Let's Encrypt SSL on Hostinger so traffic uses secure Port 443?


You

How do I set up Let's Encrypt HTTPS with Certbot on Apache on my Hostinger VPS to forward traffic through the reverse tunnel?


Gemini

Setting up Let's Encrypt HTTPS on your Hostinger Arch Linux VPS allows you to handle SSL/TLS encryption directly at the VPS level (Port 443). The VPS decrypts incoming HTTPS requests and forwards them cleanly over the local SSH reverse tunnel (127.0.0.1:8080) to your home Apache server.

Step 1: Prepare Apache VirtualHost for HTTP (Port 80)

Before running Certbot, ensure Apache on your Hostinger VPS has a functional HTTP configuration for your domain.

  1. Open (or create) your VirtualHost config file on the Hostinger VPS:
    sudo nano /etc/httpd/conf/extra/yourdomain.conf
    
  2. Add a basic Port 80 configuration pointing to your tunnel port:
    <VirtualHost *:80>
        ServerName yourdomain.com
        ServerAlias www.yourdomain.com
        ProxyPreserveHost On
        ProxyPass / http://127.0.0.1:8080/
        ProxyPassReverse / http://127.0.0.1:8080/
        # Ensure local proxy requests handle WebSocket / headers cleanly
        RequestHeader set X-Forwarded-Proto "http"
        RequestHeader set X-Forwarded-Port "80"
        ErrorLog "/var/log/httpd/yourdomain-error.log"
        CustomLog "/var/log/httpd/yourdomain-access.log" common
    </VirtualHost>
    
  3. Include the VirtualHost file in /etc/httpd/conf/httpd.conf if not already included:
    Include conf/extra/yourdomain.conf
    
  4. Verify modules are enabled in httpd.conf:
    LoadModule proxy_module modules/mod_proxy.so
    LoadModule proxy_http_module modules/mod_proxy_http.so
    LoadModule ssl_module modules/mod_ssl.so
    LoadModule headers_module modules/mod_headers.so
    
  5. Test configuration and restart Apache:
    sudo apachectl configtest
    sudo systemctl restart httpd
    

Step 2: Install Certbot and the Apache Plugin

On your Hostinger Arch Linux VPS, install Certbot and its Apache plugin via pacman:

sudo pacman -S certbot certbot-apache

Step 3: Obtain and Install the SSL Certificate

Run Certbot to acquire the certificate and automatically update your Apache configuration:

sudo certbot --apache -d yourdomain.com -d www.yourdomain.com

During the interactive setup:

  1. Enter your email address for renewal notices.
  2. Agree to the Terms of Service.
  3. Choose whether to automatically redirect HTTP traffic to HTTPS (recommended: select Option 2 to enforce HTTPS).

Certbot will automatically verify ownership of your domain via the HTTP-01 challenge on Port 80, issue the SSL certificate, create an SSL VirtualHost on Port 443, and enable HTTPS redirection.

Step 4: Verify the Apache HTTPS Configuration

Certbot will update your VirtualHost configuration on Hostinger. Your file (/etc/httpd/conf/extra/yourdomain.conf) will now look similar to this:

# Port 80: HTTP Redirect to HTTPS
<VirtualHost *:80>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com

    RewriteEngine on
    RewriteCond %{SERVER_NAME} =yourdomain.com [OR]
    RewriteCond %{SERVER_NAME} =www.yourdomain.com
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

# Port 443: Encrypted HTTPS Proxy
<VirtualHost *:443>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/

    # Inform the home application that the front-end request was HTTPS
    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"

    SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

Verify that the proxy directives (ProxyPass and ProxyPassReverse) exist inside the <VirtualHost *:443> block. If Certbot omitted them, manually add them inside the :443 block and reload Apache:

sudo apachectl configtest
sudo systemctl reload httpd

Step 5: Configure Automatic SSL Renewal

Certbot certificates are valid for 90 days. Enable the certbot.timer unit on Arch Linux to handle automated renewals in the background:

sudo systemctl enable --now certbot.timer

To test if the renewal process works cleanly without errors:

sudo certbot renew --dry-run

Verification Checklist

To confirm the setup is functional:

  1. Ensure your domain's A Record points to your Hostinger VPS public IP.
  2. Ensure your vps-tunnel.service on your home server is active and running.
  3. Visit [https://yourdomain.com](https://yourdomain.com) in a browser—it should display a valid SSL padlock and serve content from your home Apache instance.

You

Will my network speed be slower with SSH Reverse Tunnel than with Cloudflare Tunnel or WireGuard / Tailscale Subnet Routing


Gemini

Yes, an SSH reverse tunnel will generally be slower and have higher latency than WireGuard or Tailscale, though for standard web browsing on a small self-hosted site, the difference is often unnoticeable.

How SSH compares to WireGuard, Tailscale, and Cloudflare Tunnels across key performance metrics:

Performance Comparison Summary

Metric SSH Reverse Tunnel (autossh) WireGuard / Tailscale Cloudflare Tunnel (cloudflared)
Max Throughput Lowest (single-threaded CPU bottleneck) Highest (kernel-space multi-threaded) Medium–High (bounded by Cloudflare edge)
Latency / Overhead Higher (TCP-over-TCP penalty) Lowest (UDP-based, minimal headers) Low to Medium (extra hop through edge)
Stability / Reconnects Fragile (requires autossh keep-alives) Native (seamless roams across drops) High (handled by cloudflared daemon)
Protocol Scope Forwarded TCP ports only Full Layer 3 (TCP, UDP, ICMP) Application Layer (HTTP/S, TCP via WARP)

Why SSH Reverse Tunnels Are Slower

1. The "TCP-over-TCP" Problem

When a user visits your website over HTTPS (which runs on TCP), their TCP packets are wrapped inside the SSH session's TCP connection between Hostinger and your home server. If packet loss or congestion occurs on your home internet line, both the inner HTTP connection and the outer SSH tunnel will attempt TCP retransmissions independently. This leads to TCP Meltdown, where latency spikes unpredictably and throughput drops sharply. WireGuard avoids this entirely by running over UDP.

2. User-Space Processing & Single-Core Limits

SSH runs entirely in user space and processes encrypted streams sequentially. For heavy bandwidth tasks (large downloads, media streaming, high concurrent visitors), OpenSSH hits a single-core CPU bottleneck much faster than WireGuard, which processes encryption inside the Linux kernel.

3. Flow Control Overhead

SSH enforces its own internal windowing and channel flow control on top of standard TCP windows. This extra protocol overhead limits the maximum window size, resulting in lower peak transfer speeds—especially over high-bandwidth, high-latency connections.

How Other Solutions Compare

  • WireGuard / Tailscale (Fastest): Because WireGuard operates in the Linux kernel using UDP, it achieves the highest raw throughput and lowest latency. It automatically handles IP changes and network drops without breaking active sockets. Tailscale uses WireGuard under the hood with automated key coordination.
  • Cloudflare Tunnel (Easiest / Distributed): Instead of routing traffic through a single VPS IP, your home machine connects directly to Cloudflare's nearest edge server. The performance is often faster than a single VPS for geographically distributed users because traffic hits Cloudflare's global Anycast network. However, you are dependent on Cloudflare's infrastructure and ecosystem.
    Khimananda Oli+ 1

When Should You Care?

  • SSH Reverse Tunnel is fine if: You are serving lightweight dynamic web pages, personal blogs, or REST APIs with low concurrent traffic. The setup requires zero extra network kernel drivers.
  • Switch to WireGuard / Tailscale if: You plan to stream media (e.g., Plex/Jellyfin), transfer large files, or expect high concurrent traffic where low latency and maximum throughput matter.

You

Tell me how to Switch to WireGuard / Tailscale


Gemini

Switching from an SSH tunnel to WireGuard or Tailscale gives you native kernel performance, better stability during network reconnects, and eliminates TCP-over-TCP latency penalties.

Choose the path that fits your workflow:

  • Tailscale (Easiest / 5-Minute Setup): Managed WireGuard mesh. No port forwarding or manual key handling required.
  • Pure WireGuard (Maximum Control / Direct): Native Linux kernel VPN with minimal overhead.

Option 1: Tailscale (Recommended for Fast & Low-Maintenance Setup)

Tailscale manages WireGuard keys, peer connections, and NAT traversal automatically.

Step 1: Install Tailscale on Both Machines

Run the installation command on both your Hostinger VPS and your Home Server:

curl -fsSL https://tailscale.com/install.sh | sh

Step 2: Connect Both Machines to Your Tailscale Network

  1. On the Hostinger VPS, start Tailscale:
    sudo tailscale up
    
    Follow the printed link to authenticate with your account.
  2. On your Home Server, start Tailscale:
    sudo tailscale up
    
  3. Obtain the Tailscale IP of your Home Server:
    tailscale ip -4
    
    (It will look like 100.x.y.z).

Step 3: Update Apache Proxy on Hostinger VPS

Edit your Apache VirtualHost on the VPS (/etc/httpd/conf/extra/yourdomain.conf):

<VirtualHost *:443>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com

    ProxyPreserveHost On
    # Change 127.0.0.1:8080 to your Home Server's Tailscale IP
    ProxyPass / http://100.x.y.z:80/
    ProxyPassReverse / http://100.x.y.z:80/

    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"

    SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

Restart Apache:

sudo systemctl reload httpd

Step 4: Stop the Old SSH Tunnel Service

On your Home Server, disable the SSH tunnel service:

sudo systemctl disable --now vps-tunnel.service

Option 2: Pure WireGuard Setup

If you prefer a self-contained, point-to-point tunnel without external control planes:

Step 1: Install WireGuard

On both the VPS and Home Server:

sudo pacman -S wireguard-tools

Step 2: Generate Keys

  • On Hostinger VPS:
    wg genkey | tee vps_private.key | wg pubkey > vps_public.key
    
  • On Home Server:
    wg genkey | tee home_private.key | wg pubkey > home_public.key
    

Step 3: Configure Hostinger VPS (Tunnel Server)

Create /etc/wireguard/wg0.conf on your VPS:

[Interface]
PrivateKey = <VPS_PRIVATE_KEY_CONTENTS>
Address = 10.0.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <HOME_PUBLIC_KEY_CONTENTS>
AllowedIPs = 10.0.0.2/32

Enable and start WireGuard on the VPS:

sudo systemctl enable --now wg-quick@wg0

Step 4: Configure Home Server (Tunnel Client)

Create /etc/wireguard/wg0.conf on your Home Server:

[Interface]
PrivateKey = <HOME_PRIVATE_KEY_CONTENTS>
Address = 10.0.0.2/24

[Peer]
PublicKey = <VPS_PUBLIC_KEY_CONTENTS>
Endpoint = <HOSTINGER_VPS_PUBLIC_IP>:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25

Enable and start WireGuard on your Home Server:

sudo systemctl enable --now wg-quick@wg0

Step 5: Update Apache Proxy on Hostinger VPS

Update the ProxyPass targets in /etc/httpd/conf/extra/yourdomain.conf to point to the WireGuard internal IP:

ProxyPass / http://10.0.0.2:80/
ProxyPassReverse / http://10.0.0.2:80/

Reload Apache and stop your old SSH tunnel:

# On Hostinger VPS
sudo systemctl reload httpd

# On Home Server
sudo systemctl disable --now vps-tunnel.service

Verification

From your Hostinger VPS, ping your home server across the tunnel interface:

  • Tailscale: ping 100.x.y.z
  • WireGuard: ping 100.0.0.2 or ping 10.0.0.2

Once pingable, visit your website URL to confirm HTTPS traffic routes cleanly to your home Apache server over WireGuard.


You

Will this be a public server for port 80 and 443?


Gemini

Yes. Your Hostinger VPS will act as the public front door for your website, accepting traffic on standard public port 80 (HTTP) and port 443 (HTTPS).

Here is how public access and security work across the setup:

What Is Publicly Exposed vs. Private

Machine / Service Port Publicly Accessible? Purpose
Hostinger VPS 80 & 443 YES (Public) Open to the entire internet. Apache receives public web requests for yourdomain.com.
Hostinger VPS 51820 (if using WireGuard) YES (Public) Open only for your home server to establish the WireGuard VPN connection.
Home Server All Ports NO (Private) Completely hidden behind your home router/firewall. No home ports need to be opened or forwarded to the internet.
WireGuard / Tailscale Tunnel Internal IPs NO (Private) Encrypted private connection (10.0.0.x or 100.x.y.z) visible only to the VPS and Home Server.

How Security Works

  1. Visitors hit Hostinger: Anyone typing yourdomain.com connects to your VPS's public IP on port 80 or 443.
  2. Apache Proxies Internally: Apache on the VPS inspects the incoming request, terminates the SSL/TLS encryption (on port 443), and passes the raw HTTP traffic privately across the internal VPN tunnel.
  3. Home Server Stays Shielded: Your home network remains secure behind your home router. You do not need to set up port forwarding or open port 80/443 on your home router.

If your home IP changes or your home connection briefly drops, your home router's firewall continues to block all inbound public traffic, while WireGuard or Tailscale automatically re-establishes the outbound tunnel to Hostinger.