How to use ProxyForge

A practical guide to the four generators: what each setting does, where the output goes on your server, and how to test it before going live.

1. Before you start
2. Server Config Generator
3. Redirect Generator
4. SSL / Let's Encrypt Generator
5. Security Headers Generator
6. Testing and reloading safely
7. Saving and sharing a config

Before you start

• Pick your server first. Every tool has an Nginx / Apache switch at the top. The output, file name and comments change to match.
• Read the comments in the output. Lines starting with # tell you where the snippet belongs and which modules it needs.
• Back up before you edit. Copy the file you're changing first, for example sudo cp site.conf site.conf.bak.
• Paths vary by distro. Defaults assume Debian/Ubuntu layouts. On RHEL, Alma, Rocky or Fedora some file names and locations differ.

1. Server Config Generator

Builds a complete site config for a reverse proxy, WordPress, a static site or a PHP-FPM app.

Open the Config Generator →

Settings

What are you configuring?

Reverse proxy forwards requests to an app server (Node.js, Python, Go and so on). WordPress, Static site and PHP-FPM app serve files from disk, with PHP handled where needed.

Domain name

The domain the site answers on, without https:// or a trailing slash, e.g. example.com.

Backend address

Reverse proxy only: where your app is actually running, e.g. 127.0.0.1:3000.

Max upload size

Nginx's default is 1m. Raise it if your app accepts larger uploads, otherwise users get a "413 Request Entity Too Large" error.

Site root path

The folder your site's files live in, e.g. /var/www/example.com.

PHP-FPM socket

Where PHP-FPM listens: usually a Unix socket such as unix:/run/php/php8.3-fpm.sock, or a TCP address like 127.0.0.1:9000. Check your PHP version's pool config if unsure.

Redirect HTTP to HTTPS

Adds the HTTPS server block and a redirect from port 80. It assumes a certificate already exists (see the SSL generator). In Apache .htaccess mode this box is disabled, because HTTPS is configured in the virtual host, not in .htaccess.

Enable gzip compression

Compresses text responses (HTML, CSS, JS, JSON) to save bandwidth.

Support WebSocket connections

Needed for live reload, sockets or streaming APIs behind a reverse proxy.

Behind Cloudflare

Tick this if the domain is proxied through Cloudflare (orange cloud). On Nginx it adds set_real_ip_from lines for Cloudflare's published IP ranges plus real_ip_header CF-Connecting-IP, so logs and apps see real visitor IPs. On Apache the equivalent mod_remoteip lines are shown as comments, because they must go in the virtual host, not .htaccess. Either way, set Cloudflare's SSL/TLS mode to Full (strict): "Flexible" talks to your server over plain HTTP, so an HTTP-to-HTTPS redirect loops forever. Cloudflare's ranges change rarely; the current list is at cloudflare.com/ips.

Running WordPress or a PHP app and would rather not manage Nginx and PHP-FPM yourself? Kinsta offers managed WordPress hosting with free migrations, and Cloudways offers managed cloud hosting for WordPress and PHP apps on DigitalOcean, Vultr or AWS (affiliate links).

Where the output goes

Nginx (nginx.conf): save it as its own site file and enable it.

# Debian / Ubuntu
sudo nano /etc/nginx/sites-available/example.com      # paste the output
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

# RHEL / Alma / Rocky / Fedora
sudo nano /etc/nginx/conf.d/example.com.conf

Apache (.htaccess): save it as .htaccess in the site's root folder. Apache only reads it if the virtual host allows overrides (AllowOverride All), and the modules named in the comments must be enabled, e.g. sudo a2enmod rewrite proxy proxy_http on Debian/Ubuntu.

2. Redirect Generator

Creates correct redirects for the most common moves, including the differences between Nginx and Apache.

Open the Redirect Generator →

Settings

What are you redirecting?

HTTP → HTTPS, bare domain → www, www → bare domain, old domain → new domain, or a single path → a new URL.

Domain name / New domain

Plain domains, no https:// or trailing slash.

Old path

Must start with a slash and match the URL exactly, e.g. /old-page.

New URL

The full destination, including https://.

Redirect type

301 (permanent) is almost always right: browsers and search engines remember it. Use 302 (temporary) only if the move will be undone.

Where the output goes

• Nginx: domain-level redirects are their own server {} blocks, added next to your existing ones. A single-path redirect is a location block that goes inside your existing server {} (the file is named location-snippet.conf to make that clear).
• Apache: add the output to the .htaccess on the site being redirected. For a domain move, that's the old domain's server.
• Certificates: redirecting HTTPS traffic for www or the bare domain still needs a valid certificate for the name being redirected from. The output comments flag this.

Check it worked: curl -I http://example.com should show 301 and the new Location:.

3. SSL / Let's Encrypt Generator

Gives you the Certbot command to get a free certificate, plus the matching Nginx or Apache SSL config.

Open the SSL Generator →

Settings

How is Certbot obtaining the cert?

Automatic: Certbot edits your web server config for you. Webroot: Certbot only fetches the certificate and you add the config yourself. Standalone: for when no web server is running yet (Certbot briefly runs its own on port 80).

Webroot path

Must match the document root your web server already serves this domain from.

Domain(s)

Comma-separated for several names on one certificate, e.g. example.com, www.example.com.

Wildcard certificate

Covers *.example.com. It requires a DNS-01 challenge (a DNS TXT record), because Certbot can't prove ownership of a wildcard over HTTP.

Email

Used only by Let's Encrypt for renewal and expiry notices. It's deliberately left out of shareable links.

Add HSTS header

Tells browsers to always use HTTPS for this domain. Only enable it once HTTPS works reliably.

Enable OCSP stapling

Your server proves the certificate isn't revoked, so visitors' browsers don't each have to check.

Where the output goes

1. Run the Certbot command on the server.
2. Nginx: add the SSL lines to your site's server {} block that listens on 443.
3. Apache: the output has two parts. The first (SSLSessionCache, plus SSLStaplingCache when OCSP stapling is on) must go once in the main server config (httpd.conf or ssl.conf), outside any <VirtualHost>. Apache refuses to start if they're inside one. The second part goes inside your <VirtualHost *:443> block.
4. Get the current cipher line from TLSRef Configurator (choose "Intermediate") and paste it where the output comment says.

Confirm renewals will work: sudo certbot renew --dry-run.

4. Security Headers Generator

Adds the HTTP security headers most sites should send.

Open the Security Headers Generator →

Settings

Strict-Transport-Security (HSTS)

Forces HTTPS. Include subdomains applies it to every subdomain. Preload adds the flag needed to submit your domain at hstspreload.org. It automatically turns on Include subdomains, which preloading requires. Preloading is hard to undo, so only use it if every subdomain will always be HTTPS.

X-Frame-Options

Prevents clickjacking. DENY blocks all framing. SAMEORIGIN lets only your own site frame its pages.

X-Content-Type-Options: nosniff

Stops browsers guessing file types in ways attackers can exploit. Safe to leave on.

Referrer-Policy

Controls how much of your URL is sent to other sites. strict-origin-when-cross-origin is the recommended default.

Permissions-Policy

Blocks camera, microphone and geolocation access your site almost certainly doesn't use.

Content-Security-Policy (advanced)

Off by default. A wrong CSP breaks pages. The presets are starting points: Strict (same-origin only), Allow Google Fonts, and Allow Google Fonts + AdSense. Test in a browser and watch the console for CSP errors before relying on one.

Where the output goes

• Nginx: inside your server {} block. Gotcha: add_header doesn't inherit into a location block that has its own add_header lines, so repeat the headers there too or they silently disappear for those requests.
• Apache: inside your <VirtualHost> or .htaccess. Requires mod_headers (sudo a2enmod headers on Debian/Ubuntu).

Check them: curl -I https://example.com lists the headers your site sends.

Testing and reloading safely

Always test the config before reloading. A reload with a broken config can take your site down.

# Nginx
sudo nginx -t && sudo systemctl reload nginx

# Apache (Debian / Ubuntu)
sudo apachectl configtest && sudo systemctl reload apache2

# Apache (RHEL / Alma / Rocky / Fedora)
sudo apachectl configtest && sudo systemctl reload httpd

The && means the reload only happens if the test passes. If the test fails, the error names the file and line. Fix it, or restore your backup.

Saving and sharing a config

Your settings are stored in the page address after the #. That means:

• Refreshing the page or using the back button keeps your settings.
• You can bookmark a config, or send the link to a colleague and they'll see exactly the same output.
• The part after # is never sent to any server. The SSL generator deliberately leaves your email out of the link.

Questions or a wrong result?

If a generated config doesn't work on your distro or setup, or you'd like another generator, email admin@proxyforge.tech.