Put NGINX on the public HTTP(S) edge, point your mail hostname to it, terminate TLS on port 443, and proxy web requests to iRedMail’s private web listener. Keep SMTP, IMAP and POP3 separate: an HTTP location block can proxy Roundcube, SOGo, iRedAdmin and Netdata, but it cannot proxy mail protocols. Those require NGINX’s separate top-level mail {} configuration and mail modules.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The safest design leaves databases, LDAP and application services on private or localhost-only listeners, while the edge exposes only the ports your users need. The procedure below covers DNS, same-host and separate-host layouts, path and subdomain routing, certificates, generated iRedMail templates, mail-protocol proxying, validation and the failure modes that most often break a deployment.
As an Amazon Associate I earn from qualifying purchases.
What the finished architecture looks like
A client resolves mail.example.com to the NGINX edge. NGINX accepts HTTP on port 80 and HTTPS on port 443, redirects clear-text requests to HTTPS, and forwards the request to the iRedMail web service over a private address and port. The backend can be on the same machine, listening on a private port, or on another host reachable over an internal network.
iRedMail’s standard web applications use these paths:
/mailfor Roundcube/SOGofor SOGo/iredadminfor iRedAdmin/netdatafor Netdata
SMTP, IMAP and POP3 do not travel through those paths. Their normal public ports are 25 for server-to-server SMTP, 587 for message submission, 993 for encrypted IMAP and 995 for encrypted POP3. Port 465, historically used for SMTP over SSL, is deprecated in iRedMail’s port guidance; use 587 for submission instead.
Choose the proxy layout before editing NGINX
| Layout | Where NGINX listens | Backend arrangement | Main consideration |
|---|---|---|---|
| Separate proxy host | Public ports 80 and 443 on a front-end server | iRedMail web service is reached over a private network address and port | Clearly separates the public edge from the mail server, but requires an internal route and firewall rule |
| Same host, private backend port | Public ports 80 and 443 on the iRedMail machine | iRedMail web service is moved or bound to a private port such as an internal HTTP listener | Simple network topology, but port ownership and upgrade behavior must be planned carefully |
| Path-based web routing | One HTTPS hostname | Applications are reached at paths such as /mail and /SOGo |
Matches iRedMail’s documented default paths |
| Subdomain routing | One HTTPS listener with multiple hostnames, or separate server blocks | Each hostname uses an iRedMail application template or a matching proxy rule | Requires DNS records and certificates covering every hostname |
| HTTP reverse proxy only | 80 and 443 | Roundcube, SOGo, iRedAdmin and other web interfaces | Does not provide SMTP, IMAP or POP3 access for mail clients |
| Full mail proxy | Mail ports such as 25, 587, 993 and 995 | NGINX mail {} context forwards protocols to mail servers |
Needs mail modules, an authentication service and protocol-specific TLS settings |
Do not point a same-host reverse proxy at the backend’s existing public 443 listener without changing the design. That can create a TLS loop, bind conflict or a request that returns to the proxy instead of reaching the application. Use a private backend port or place NGINX on another host.
Recommended Free Tools
Prepare DNS, certificates and firewall rules
1. Select the public name
Choose a name such as mail.example.com or webmail.example.com. Create an A record for IPv4 and, when the edge is reachable over IPv6, an AAAA record. Both records must point to the NGINX edge, not accidentally to an old iRedMail address. A subdomain deployment works only when the hostname resolves to the endpoint serving that subdomain.
2. Decide which services are public
For webmail, expose 80 and 443 at the edge. Mail clients still need the mail ports they use: 587 for submission, 993 for encrypted IMAP and, if POP3 is required, 995. Port 25 is used for server-to-server SMTP and is commonly needed for mail delivery. Do not expose database, LDAP, SOGo or other application backends merely because NGINX is present; iRedMail’s normal design keeps those services on localhost or an internal interface.
3. Obtain a trusted certificate
iRedMail’s ssl.tmpl uses a self-signed certificate by default. That is unsuitable for a public service because browsers and mail clients will display trust errors. Request a certificate from a trusted certificate authority for every public name you publish. One certificate can cover multiple names when its subject names include them. Install the full certificate chain and private key on the NGINX edge, and arrange renewal before expiry.
4. Confirm the backend listener
Before writing proxy_pass, identify the address and port where the iRedMail web service actually listens. It may be a local HTTP listener, an internal HTTPS listener, or an application server behind the web server installed by iRedMail. Record whether the backend expects the original host, a path prefix and HTTP or HTTPS. The example below uses 127.0.0.1:8080 only as a placeholder; replace it with the real private listener.
Build the public HTTP and HTTPS server blocks
A minimal edge configuration has one server block that redirects HTTP and another that terminates TLS and proxies requests:
server {
listen 80;
listen [::]:80;
server_name mail.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name mail.example.com;
ssl_certificate /etc/letsencrypt/live/mail.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mail.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}The redirect preserves the requested path and query string. The HTTPS block keeps the public hostname in Host, records the original client address in forwarding headers and tells the backend that the client used HTTPS. Those values matter for absolute redirects, secure-cookie decisions and audit logs. Match the header set to the templates and web stack installed on your system; iRedMail does not prescribe one universal proxy_pass arrangement for every installation.
Use TLS 1.2 and TLS 1.3 in the edge policy, following the NGINX TLS configuration supported by your distribution. Do not copy a certificate path from the example unless that file exists on your host.
Use iRedMail’s generated templates when NGINX runs with iRedMail
When NGINX is installed on the iRedMail host, generated templates are usually safer than replacing the complete iRedMail configuration with a hand-written proxy. For a subdomain, iRedMail documents a server block that includes the common templates misc.tmpl and ssl.tmpl, followed by the application template that matches the service:
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsroundcube-subdomain.tmplfor Roundcube- the SOGo subdomain template for SOGo
- the iRedAdmin subdomain template for iRedAdmin
The enabled site is then linked into the distribution’s sites-enabled directory. Keep the generated include order intact. The common templates provide shared behavior, while the application-specific template supplies the locations and backend details that the installed iRedMail version expects.
Choose templates when you want iRedMail’s upgrade and application conventions to remain authoritative. Choose a separate edge configuration when NGINX is on another host and iRedMail is only a private upstream. In either case, inspect the resulting server block so that the public hostname, certificate paths and backend address agree with your deployment.
Path-based access to Roundcube, SOGo and administration
Roundcube at /mail
With the standard iRedMail layout, users open https://mail.example.com/mail. Preserve that path when proxying. If you instead proxy the application at the root path, links or redirects generated for /mail may point to the wrong location. Test both the initial page and a login redirect.
SOGo at /SOGo
SOGo uses a capitalized path in iRedMail’s documented layout. Paths are case-sensitive on many Linux web stacks, so do not silently change /SOGo to /sogo unless you also configure the backend and redirects for that spelling. SOGo may use additional request paths for its web interface and services; the generated SOGo template is preferable to guessing individual locations.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iRedAdmin at /iredadmin
Expose iRedAdmin only when administrators need it. Restricting access at the edge by network, VPN or an additional authentication layer is prudent because this interface changes mail domains and accounts. At minimum, verify that the proxy sends the original host and HTTPS scheme so the administration interface does not redirect to an internal name.
Netdata at /netdata
Netdata is another documented web path. Treat it as an operations endpoint rather than a public marketing page. If it is not required externally, leave the location private or omit it from the public server block.
Subdomain routing instead of path routing
Some deployments use separate names such as webmail.example.com for Roundcube and sogo.example.com for SOGo. Each name needs DNS pointing to the NGINX edge and a certificate that covers that name. A dedicated server block can include the common NGINX templates and the matching application-specific subdomain template, as documented by iRedMail.
Subdomains simplify application paths because the browser starts at the application’s own root, but they increase certificate and DNS administration. Path routing keeps one certificate and hostname, while subdomains make it easier to apply different access controls or send users directly to one application. Do not mix the two accidentally: a certificate for mail.example.com does not automatically cover webmail.example.com.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Proxying SMTP, IMAP and POP3 is a separate project
An HTTP location block understands HTTP requests only. It cannot forward an SMTP submission, IMAP session or POP3 session. If the edge must proxy those protocols, configure NGINX’s mail proxy feature in a top-level mail {} context.
The NGINX mail-proxy design requires all of the following:
- An NGINX build with the mail module, enabled with
--with-mail. - The mail SSL module, enabled with
--with-mail_ssl_module, when NGINX terminates TLS for mail protocols. - An HTTP authentication server that tells NGINX which upstream mail server should receive the session.
- Protocol-specific
serverblocks inside themail {}context. - Explicit certificates and TLS settings for encrypted submission, IMAP and POP3.
Keep the protocol ports distinct. Use 587 for authenticated SMTP submission, 993 for encrypted IMAP and 995 for encrypted POP3. Port 25 remains the server-to-server SMTP endpoint where required. A functioning Roundcube page proves only that HTTP proxying works; it says nothing about authentication or reachability on these mail ports.
Mail proxying also changes certificate ownership and logging. Decide whether NGINX or the iRedMail backend terminates TLS, ensure the certificate name matches the hostname configured in mail clients, and test each protocol independently. Do not place mail-proxy directives inside an HTTP server block.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteEnable, validate and reload safely
- Save the server block in the location used by your distribution or iRedMail’s generated site layout.
- If your distribution uses separate site directories, create the enabled-site link expected by that layout.
- Run the NGINX configuration syntax check, commonly
nginx -t. Fix every reported error before reloading. - Reload NGINX with the service manager used by your system, commonly
systemctl reload nginx. A reload applies the new configuration without intentionally dropping existing connections. - Request
http://mail.example.com/and confirm a 301 redirect to the HTTPS URL with the same path. - Open
https://mail.example.com/mail,/SOGo,/iredadminand/netdataonly for the applications you enabled. - Check the certificate chain from a normal client and confirm that no self-signed warning appears.
- Test SMTP submission, IMAP and POP3 separately if those ports are part of the design.
Perform tests from outside the server’s local network as well as from an internal machine. A local request can succeed even when DNS, firewall rules or NAT prevent real users from reaching the edge.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Security and operational checklist
- Expose only 80, 443 and the mail ports required by your user and delivery model.
- Keep databases, LDAP and application backends bound to localhost or a private interface, as in iRedMail’s default port guidance.
- Use a trusted certificate and renew it before expiration; replacing a certificate after clients begin rejecting it creates an avoidable outage.
- Preserve
Host,X-Real-IP,X-Forwarded-ForandX-Forwarded-Protounless your installed templates require different names. - Do not send proxy traffic to the same public 443 socket on the same host unless the backend has deliberately been moved to a private listener.
- Restrict administrative paths such as
/iredadminand operational dashboards when they do not need public access. - Keep web and mail tests separate in monitoring. A healthy HTTPS check is not an SMTP, IMAP or POP3 health check.
- Record which machine owns each port and certificate. This prevents an upgrade from starting a second service on a port already owned by the edge.
Troubleshooting by symptom
HTTP redirects to an internal hostname
The backend is probably unaware of the public host or HTTPS scheme. Check proxy_set_header Host and proxy_set_header X-Forwarded-Proto, then compare the active configuration with the iRedMail template for your application. Also verify that DNS is reaching the intended edge rather than an older server.
502 Bad Gateway
NGINX cannot connect to the configured upstream, or the upstream speaks a different protocol. Confirm the private address and port, check the backend listener locally, and ensure a firewall permits traffic from the proxy host. If the backend expects HTTPS, do not use an HTTP proxy_pass; if it is plain HTTP, do not create an unnecessary TLS loop.
Certificate warnings
Verify that the certificate includes the exact hostname users enter, that the full chain is installed and that NGINX is loading the intended file. A self-signed certificate from ssl.tmpl will continue to trigger warnings until replaced with a trusted certificate.
Roundcube works but SOGo or iRedAdmin returns 404
Check the case and spelling of the path, and confirm that the relevant application template or location is enabled. /SOGo is not interchangeable with a lowercase path on a case-sensitive backend. Do not assume that a root proxy automatically exposes every iRedMail application path.
Webmail works but mail clients cannot send or receive
HTTP success does not test mail protocols. Check that the required ports are listening on the intended host, that firewall and NAT rules forward them, and that the client is configured for 587 submission, 993 encrypted IMAP or 995 encrypted POP3 as appropriate. If NGINX is meant to proxy those sessions, verify the mail modules, authentication service and mail {} configuration independently.
NGINX fails to reload after an edit
Run the syntax check again and read the exact file and line reported. Common causes are placing mail directives in the HTTP context, duplicating a server declaration for the same address, misspelling a certificate path or enabling a site link to a removed file. Restore the last known-good configuration before attempting another change.
Practical decision guide
Use a separate NGINX host when you want a clear security boundary, centralized certificate management or a public edge that can be rebuilt without touching the mail server. Use same-host NGINX when resources and network simplicity matter, but reserve a private backend port and verify how iRedMail upgrades regenerate templates.
Choose path routing when one hostname and one certificate are more important than application isolation. Choose subdomains when each application needs its own access policy, branding or direct bookmark. Terminate HTTPS at NGINX when the edge is trusted and you need centralized certificates; pass encrypted traffic onward only when the backend must own TLS and your design deliberately accounts for the extra certificate and port management.
For a normal webmail deployment, the smallest reliable design is: DNS to NGINX, ports 80 and 443 open at the edge, a trusted certificate, a private HTTP upstream, preserved forwarding headers and the documented iRedMail paths. Add SMTP, IMAP or POP3 proxying only after the web path is stable, because it uses a different NGINX configuration context and a separate testing plan.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
