{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }}

Use a bare host such as example.com or app.example.com.
{{ issueFor('server_name') }}
Enable only when DNS and certificate coverage include the www hostname.
{{ params.include_www_alias ? 'Included' : 'Not included' }}
Use a monitored mailbox or team alias.
{{ issueFor('server_admin') }}
Static and PHP-FPM modes use a public document root; proxy mode forwards to an application server.
Example: /var/www/example.com/public
{{ issueFor('document_root') }}
Use a trailing slash for a root proxy, for example http://127.0.0.1:3000/.
{{ issueFor('backend_url') }}
Common Debian path: /run/php/php8.3-fpm.sock.
{{ issueFor('php_fpm_socket') }}
Redirect plus HTTPS is the normal public-site target after DNS and certificates are ready.
The generated paths are not checked against the server filesystem.
Example: /etc/ssl/certs/example.com-fullchain.pem
{{ issueFor('cert_file') }}
Example: /etc/ssl/private/example.com.key
{{ issueFor('cert_key') }}
Public is normal for web content; local or denied can stage a document-root site before launch.
This changes log paths, file placement, module commands, and the reload service name.
Apache must be able to create or write the selected log files.
{{ issueFor('custom_log_dir') }}
Leave blank unless DNS and certificate coverage include more names.
{{ issueFor('extra_aliases') }}
Use *, _default_, an IP address, an IPv6 address in brackets, or a resolvable interface name.
{{ issueFor('bind_address') }}
Port 80 is standard for HTTP.
port
{{ issueFor('http_port') }}
Port 443 is standard for HTTPS.
port
{{ issueFor('https_port') }}
None is the narrow default; All is flagged for explicit review.
PHP front controllers commonly put index.php before index.html.
The default disables directory indexes and keeps common deployment symlinks available.
warn is the normal production default.
Keep HSTS off until certificates, redirects, subdomains, and recovery paths are confirmed.
Comments do not change Apache behavior.
{{ params.include_comments ? 'Included' : 'Not included' }} 
{{ values.config_text }}
AreaCheckStatusEvidence and next actionCopy
{{ row.area }}{{ row.label }}{{ row.status }}{{ row.evidence }} {{ row.next_action }}
DirectiveValueDeployment noteCopy
{{ row.directive }}{{ row.value }}{{ row.note }}
StepCommand or checkReasonCopy
{{ row.step }}{{ row.command }}{{ row.reason }}
NGINX Proxy Headers Checker Audit an NGINX proxy block for unsafe forwarded headers and trust-boundary gaps with checks for WebSocket, timeout and upstream TLS risks.
Nginx Server Block Generator Generate an NGINX server block for static sites, PHP-FPM apps, or reverse proxies with TLS routing plus safety and activation checks.
Hypertext Transfer Protocol (HTTP) Redirect Checker Trace a public HTTP redirect chain hop by hop to identify loops and HTTPS downgrades, compare timing and generate a replayable cURL command.
HAProxy Backend Config Generator Build an HAProxy backend block from server rows with health checks and TLS trust choices, then review capacity limits and deployment warnings.

One Apache server can answer for many hostnames on the same address. A virtual host, or vhost, gives one of those names its own content handoff, access policy, TLS settings, and logs. The configuration is compact, but a wrong name, port, alias, or file order can route a request to the wrong site without producing an obvious syntax error.

Request matching happens in stages. Apache first chooses the best local address and port, then compares the requested hostname with ServerName and ServerAlias among the vhosts on that listener. If none of those names match, the first vhost for the selected address and port becomes the default. DNS only brings the client to the server; it does not decide which Apache vhost handles the request.

Apache request narrowed by address and hostname before a filesystem, PHP-FPM, or reverse-proxy handoff.

The content handoff depends on the site. Static and front-controller sites serve files under a DocumentRoot and need a matching <Directory> access block. PHP-FPM adds a handler that forwards PHP files to a Unix socket or network target. A reverse proxy uses ProxyPass and ProxyPassReverse to send requests to an HTTP backend while keeping forward-proxy behavior off.

TLS adds another listener, certificate paths, and module dependencies. An HTTP-to-HTTPS plan needs both a redirect vhost on the HTTP port and a secure content vhost on the HTTPS port. An HTTPS-only vhost assumes the HTTP redirect is handled somewhere else or that port 80 is intentionally unavailable. Neither arrangement is safe to deploy until the certificate covers every public name and Apache is listening on the selected ports.

Canonical name
The primary ServerName used for matching, certificate checks, and smoke tests.
Alias scope
Every extra hostname that should reach the same vhost. DNS and certificate coverage must agree with this list.
Public boundary
The directory or backend that Apache exposes after the match. Private source, secrets, and storage should stay outside it.
Activation guard
A syntax test and host-level smoke test performed before and after a reload.

High Strict Transport Security (HSTS) deserves separate care. Once a browser receives it over HTTPS, the browser can force future requests to HTTPS for the policy lifetime. Including subdomains or requesting preload affects names beyond the current vhost and can be difficult to reverse. Enable it only after HTTPS works reliably for the intended scope.

How to Use This Tool:

Draft from the server's real routing and deployment plan, not from a hostname alone.

  1. Enter ServerName, the monitored ServerAdmin address, and only the aliases that already have intentional DNS and certificate coverage.
  2. Choose Site mode. For files or PHP-FPM, confirm the absolute DocumentRoot; for a reverse proxy, enter an absolute HTTP or HTTPS Backend URL that is reachable from the Apache host.
  3. Select the TLS plan, certificate path profile, access policy, and Apache layout. Review advanced ports, bind address, override scope, directory options, log level, and HSTS only when they match the target host.
  4. Read Review checks and resolve every Review item. Verify the required module list, public content boundary, certificate files, aliases, and distribution-specific paths before saving the vhost.
  5. Follow Activation plan in order. Save and enable the file, verify modules, run sudo apachectl configtest, and stop on any error. Reload only after a clean syntax result, then test DNS or SNI and request the public hostname.

Interpreting Results:

Ready means the draft passed the page's deterministic input and policy checks. It does not mean Apache has parsed the file, loaded every module, found the certificate, reached the backend, or selected this vhost for a real request.

  • Resolve each review warning before activation, especially HTTP-only launches, missing redirects, broad AllowOverride, unusual document roots, wildcard aliases, and HSTS preload.
  • Use apachectl configtest as the syntax gate and apachectl -S when hostname or default-vhost selection is unclear.
  • Finish with a request through the intended hostname. A successful request to the backend alone does not prove that Apache routing, TLS, redirects, or response headers are correct.

Technical Details:

A generated vhost follows an ordered decision pipeline: normalize and validate the host inputs, determine aliases and modules, render one or two vhost blocks, then derive review checks and activation commands from the same normalized choices. No generated status bypasses Apache's own parser.

Rule Core:

Site mode Content directives Required modules Important boundary
Static files or front controller DocumentRoot, <Directory>, DirectoryIndex, Options, AllowOverride, Require Core directives only, before TLS additions The document root must be an absolute path and should expose only public files.
PHP-FPM Static rules plus a PHP FilesMatch handler proxy, proxy_fcgi, setenvif The PHP-FPM socket or host-and-port target must exist on the server.
HTTP reverse proxy ProxyRequests Off, ProxyPreserveHost On, forwarded scheme, ProxyPass, ProxyPassReverse headers, proxy, proxy_http The backend URL must be absolute, use HTTP or HTTPS, and end with a normalized slash.

TLS and HSTS Rules:

Plan Vhost blocks Generated behavior Review rule
HTTP only 1 Content on the HTTP port, no certificate directives Always reports that a public production launch still needs a TLS plan.
HTTP redirect plus HTTPS 2 Permanent HTTP redirect plus secure content vhost Requires ssl and alias; HSTS or proxy mode also requires headers.
HTTPS only 1 Secure content vhost only Reports that the port-80 redirect must exist elsewhere or be intentionally absent.

TLS certificate paths use either absolute custom files or the conventional Let's Encrypt live directory for the canonical hostname. HSTS is emitted only inside an HTTPS vhost: one year for the site-only policy, the same lifetime plus includeSubDomains for subdomain scope, and an additional preload token for the preload choice. The preload choice always produces a review warning.

Validation and Deployment Boundaries:

Input or decision Exact boundary Failure or warning
Server name Valid hostname, IPv4 address, or localhost; no wildcard Invalid identity blocks generation.
Extra aliases Valid names; a leading wildcard is allowed Wildcard scope produces a review warning.
HTTP and HTTPS ports Whole numbers from 1 through 65,535 Out-of-range ports block generation.
Filesystem paths Required paths must be absolute Relative document roots, custom certificates, or custom log directories are rejected.
AllowOverride All Allowed for file-based sites Produces a warning because it grants broad .htaccess control.
Activation Debian-family uses sites-available and a2ensite; RHEL-family uses conf.d Generated commands still need review against the actual host.

The vhost text, warnings, module list, directive ledger, and activation plan are produced locally from the same choices. They do not inspect DNS, the filesystem, loaded modules, the Apache include order, firewall rules, certificates, backend health, or the live response.

Security and Deployment Notes:

Treat the result as a draft for a named host, not as a change that is safe to paste and reload without review.

  • Keep secrets, source code, environment files, and private storage outside the served document root.
  • Verify every alias in DNS and in the certificate's hostname coverage before enabling it.
  • For a reverse proxy, test backend reachability from the Apache host and confirm redirects, cookies, WebSockets, and forwarded headers expected by the application.
  • Use a temporary HSTS policy while testing. Do not enable subdomain or preload scope until recovery and every affected hostname are understood.
  • Configuration drafting stays in the browser. Deployment occurs only when you run the reviewed commands on the server.

Worked Examples:

Static site still using HTTP

For example.com, a public document root at /var/www/example.com/public, Debian layout, and HTTP-only service, the draft contains one vhost block and no extra modules. The status remains Review needed because a public launch still lacks a TLS plan.

RHEL reverse proxy with HTTPS redirect

For app.example.net proxying to a loopback backend on port 8080, the HTTP-to-HTTPS plan emits two blocks and requires ssl, alias, headers, proxy, and proxy_http. A site-only one-year HSTS policy has no local warning, but readiness still depends on the RHEL module check, syntax test, certificate test, and public smoke request.

References: