The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Put NGINX at the public HTTP(S) edge, terminate TLS there, and forward web requests to iRedMail over a private listener. Keep SMTP, IMAP and POP3 separate: an HTTP location block can proxy Roundcube or SOGo, but mail-client traffic requires NGINX’s distinct mail {} proxy context, mail modules and an authentication service. iRedMail normally exposes web traffic on ports 80 and 443, while mail clients use 587, 993 and 995 and server-to-server delivery uses 25.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
What the finished design looks like
Point the public hostname, such as mail.example.com, to the NGINX edge. NGINX listens on public ports 80 and 443, redirects HTTP to HTTPS, presents the trusted certificate, and sends HTTP requests to the iRedMail web service on a private address and port. The backend should not need to be reachable from the internet.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
In a typical installation, the web applications are available at these paths:
/mail— Roundcube/SOGo— SOGo/netdata— Netdata/iredadmin— iRedAdmin
These paths are independent of mail protocols. A successful Roundcube page only proves that HTTP proxying works; it does not test SMTP submission or IMAP authentication.
The public edge should have one clear responsibility: accept client HTTP connections, apply the certificate and routing policy, and pass the request to the intended iRedMail service. Keep the internal address, backend port and any local-only services out of public DNS and firewall rules. This separation makes it easier to audit which machine owns a port and to replace either the edge or the mail server later.
Choose the proxy arrangement before editing NGINX
| Arrangement | How it works | Advantages | Risks and checks |
|---|---|---|---|
| NGINX on a separate edge host | DNS points to the edge host; NGINX forwards to iRedMail over a private network. | Clear port ownership, isolated public attack surface, and no same-machine listener collision. | The edge must reach the backend privately, and firewall rules must allow only the required backend port. |
| NGINX on the iRedMail host | NGINX owns public 80/443 and forwards to iRedMail on localhost or another private port. | No extra server or network hop. | You must identify the existing web listener and avoid forwarding back to the same public 443 socket. |
| Path-based web routing | One hostname exposes paths such as /mail and /SOGo. |
Simple DNS and one certificate name. | Each application must support the chosen path and its redirects, cookies and WebSocket requirements. |
| Subdomain routing | Separate names, for example webmail.example.com, route to an application template. |
Cleaner application URLs and simpler per-application policies. | Every name needs DNS and certificate coverage. |
| HTTP proxy only | NGINX handles Roundcube, SOGo and administration pages. | Uses ordinary http server and location blocks. |
Mail clients still connect directly to ports 25, 587, 993 or 995. |
| Full mail proxy | NGINX’s separate mail {} context proxies SMTP, IMAP and POP3. |
One public mail endpoint can front multiple backend mail servers. | Requires mail modules, an HTTP authentication service and protocol-specific TLS configuration. |
Path routing is usually the least disruptive choice when users already know the iRedMail URLs. A subdomain can be cleaner for branding or for applying a separate access policy, but each additional name must be present in DNS and in the certificate. Do not select a subdomain merely to avoid learning the existing path; use the application-specific iRedMail template so aliases and redirects remain correct.
A separate edge host provides the strongest boundary, but it adds a private-network dependency and another system to patch. A same-host arrangement is compact, yet it requires careful listener ownership and closer attention to iRedMail-generated files during upgrades.
Ports and boundaries to preserve
| Port | Purpose | Proxy decision |
|---|---|---|
| 80 | HTTP | Usually redirect to HTTPS at NGINX. |
| 443 | HTTPS web applications | Terminate TLS at NGINX and proxy HTTP to the private iRedMail listener. |
| 25 | Server-to-server SMTP | Keep as a mail-protocol path; do not place it in an HTTP location. |
| 587 | Authenticated SMTP submission | Recommended submission port; configure and test independently from webmail. |
| 993 | Encrypted IMAP | Requires mail proxying or direct exposure, not HTTP reverse proxying. |
| 995 | Encrypted POP3 | Requires mail proxying or direct exposure, not HTTP reverse proxying. |
| 465 | SMTP over SSL | iRedMail marks it deprecated; use 587 for submission. |
Databases, LDAP, SOGo internals and other application services are normally localhost-only in iRedMail. Preserve that boundary unless your design explicitly requires a private-network connection.
Port ownership should be written down before deployment. On a same-host design, NGINX normally owns 80 and 443 while the backend uses a private port. On a separate edge, the edge owns public 80 and 443 and the mail host firewall permits only the selected internal web port from the edge address. Do not open every backend port just because the edge can route traffic; SMTP, IMAP, databases and LDAP each have different security and operational requirements.
Step 1: Plan the hostname and DNS
- Choose the public name, such as
mail.example.comorwebmail.example.com. - Create an A record, and an AAAA record if IPv6 is enabled, pointing to the NGINX edge.
- If NGINX is on another host, confirm that the edge can reach the iRedMail backend over a private address and port.
- Decide whether users will use the existing paths (
/mail,/SOGo) or a dedicated subdomain. Do not change paths casually; application redirects and generated templates may assume the documented layout.
DNS must resolve to the edge that owns the certificate and public ports. If it still points directly to the iRedMail host, requests will bypass the reverse proxy.
Check both address families if you publish A and AAAA records. An incorrect AAAA record can send some clients to a host that does not have the certificate or NGINX listener, while IPv4 tests appear healthy. Confirm that the selected hostname is the exact name users will enter; certificate names, NGINX server_name values and DNS records must agree.
Step 2: Identify the real iRedMail backend listener
Before writing proxy_pass, determine which web server iRedMail uses and where it listens. It may be bound to localhost or to a private interface on a non-public port. Record the address, port, and whether the backend expects HTTP or HTTPS.
- Do not proxy from NGINX to
https://127.0.0.1:443merely because the public site uses 443. On the same host this can create a loop or collide with the listener NGINX is supposed to own. - If the backend currently owns 443, move it to a deliberate private port or place NGINX on a separate host.
- Use the installed iRedMail templates as the authority for paths and TLS settings; a generic proxy block cannot account for every stack or upgrade.
Confirm the listener locally before testing through DNS. A backend that is bound only to loopback cannot be reached from a separate edge host; a backend bound to a private interface still needs a firewall rule allowing the edge. If the service expects HTTPS, decide whether the private hop will verify its certificate or use protected HTTP on the private network. Make that choice explicit rather than silently disabling certificate checks.
Step 3: Create the public HTTPS server
The following is a deployment pattern. Replace the backend address and port with the listener you identified, and adjust path handling to match the installed iRedMail stack.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
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 example preserves the original host, client address and public scheme. Those values help backend redirects, generated links and audit logs refer to the public request rather than the internal hop. Confirm the exact header requirements against your installed templates before applying them.
If the backend itself requires HTTPS, use a private HTTPS listener and configure certificate verification deliberately. Do not assume that forwarding to the public 443 endpoint is safe on a same-host installation.
The catch-all location / shown here is intentionally generic. If you publish only one application, a narrower location can reduce accidental exposure; if you publish several documented paths, retain the aliases and restrictions supplied by the corresponding iRedMail templates. Avoid adding broad rewrites until you have observed the application’s normal redirects, because changing a path prefix can break cookies or produce links that point to an internal hostname.
Step 4: Use iRedMail’s generated templates when they fit
When NGINX runs on the iRedMail host, the project’s generated templates are often safer than replacing the complete virtual-host configuration with a hand-written block. The documented subdomain pattern includes the general templates misc.tmpl and ssl.tmpl, plus an application template such as roundcube-subdomain.tmpl. Use the SOGo or iRedAdmin equivalent when that is the application being published, then enable the resulting site with the distribution’s normal site symlink mechanism.
Free tools Windows power users keep installed
One-click scans. No signup required.
Template-based configuration keeps application-specific aliases, headers and restrictions aligned with iRedMail updates. If you add custom proxy rules, keep them in the supported extension point or document them so an upgrade does not silently remove them.
The generated subdomain pattern is also useful when you want NGINX to serve the application directly rather than proxying to another machine. Include the common template files exactly as the project documents, create the server block for the selected name, and enable it through the normal sites-enabled link. Do not copy a Roundcube template for SOGo simply because both are web applications; each has its own path and application behavior.
Step 5: Install a certificate clients will trust
The default ssl.tmpl configuration uses a self-signed certificate. That is unsuitable for a public webmail URL because browsers and mail-related web components will show trust errors. Request a free certificate from a trusted certificate authority and configure its full chain and private key at the NGINX edge. One certificate can cover multiple names when your DNS and certificate request use those names.
Renew the certificate before expiry and reload NGINX after renewal. Test from a client that does not already have the self-signed certificate installed; otherwise a local trust exception can hide a deployment problem.
Certificate coverage must include every public name you actually publish. A certificate for mail.example.com does not automatically cover webmail.example.com. Keep the private key readable only by the services that need it, and make sure a renewal process updates the edge certificate rather than only changing a file on the backend. After renewal, verify both the normal HTTPS page and any subdomains before declaring the change complete.
Step 6: Validate, enable and reload
- Run the NGINX configuration syntax check supplied by your distribution (the common form is
nginx -t). - Resolve the hostname and confirm that ports 80 and 443 reach the intended edge host.
- Reload NGINX using your operating system’s service manager; use a restart only when a reload is unavailable or the change requires it.
- Request the HTTP URL and verify a 301 redirect to the HTTPS URL.
- Open
/mail,/SOGoand/iredadminas applicable. Check/netdataonly if you intentionally publish it; monitoring interfaces should not be exposed accidentally. - Sign in and follow a redirect or logout flow to verify that the backend understands the original host and HTTPS scheme.
- Test SMTP submission on 587 and encrypted IMAP on 993 separately. If you support POP3, test 995 as well.
Perform the checks from outside the server’s local network as well as from the edge itself. Internal success can hide a public DNS, firewall or certificate problem. Review NGINX and backend logs during a test request: the public host, client address and forwarded scheme should be consistent, and a failed request should identify whether the error occurred at the edge or on the iRedMail service.
Proxying SMTP, IMAP and POP3 is a different configuration
NGINX HTTP reverse proxying cannot carry SMTP, IMAP or POP3. NGINX provides a separate mail-proxy feature in a top-level mail {} context. The official NGINX design requires mail modules (compiled with --with-mail, and --with-mail_ssl_module when TLS support is needed), an HTTP authentication server, protocol-specific server blocks, and explicit certificate and TLS settings.
That mail configuration is a separate decision from publishing Roundcube. It must map each protocol and public port to the appropriate backend and authentication flow. Keep the documented iRedMail ports as the reference: 25 for server-to-server SMTP, 587 for authenticated submission, 993 for encrypted IMAP and 995 for encrypted POP3. Port 465 is deprecated by iRedMail and should not be selected for a new submission design.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →If you do not need a single proxy endpoint for mail clients, leaving these protocols on their normal iRedMail listeners is simpler. In either design, firewall rules should expose only the ports you actually operate.
Do not infer mail-proxy readiness from the presence of the normal NGINX package. Confirm that the installed build includes the mail modules, then plan the authentication service and TLS certificates for each protocol. A mail proxy also changes where client source addresses and connection logs appear, so document the backend trust boundary and test authentication failures as well as successful logins.
Same-host deployment versus a separate edge host
NGINX on the iRedMail host
- Give NGINX ownership of public 80 and 443.
- Move or retain the iRedMail web service on a private listener that NGINX can reach.
- Use iRedMail’s generated templates where possible.
- Check every package upgrade for changes to generated files and reapply only documented customizations.
This option minimizes network hops and keeps the private hop on loopback, but a configuration error can affect both the edge and the mail host at once. Keep a known-good server block and the intended backend port recorded so recovery does not depend on guessing which process owns 443.
NGINX on another server
- Point DNS and the certificate at the edge host.
- Permit the edge’s private address to reach only the required iRedMail web port.
- Keep databases, LDAP and internal application ports inaccessible from the edge unless explicitly required.
- Decide whether the edge-to-backend hop is HTTP on a protected private network or HTTPS with deliberate certificate validation.
This arrangement makes replacement or scaling of the edge easier, but it introduces a dependency on private routing, firewall state and the backend’s bind address. Document the private address rather than using a name that could later resolve to the public edge and create a loop.
Crashes, 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 minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Troubleshooting by symptom
HTTP redirects repeatedly or returns a 502
A loop usually means the backend is redirecting to the public HTTPS URL while NGINX is forwarding to an endpoint that resolves back to itself. A 502 generally means the private address or port is wrong, the backend is stopped, or a firewall blocks the edge. Confirm the listener locally on the iRedMail host and verify that NGINX is not targeting its own public socket.
The page loads, but links return to the wrong hostname or HTTP
Check the Host and X-Forwarded-Proto values received by the backend. Missing or incorrect forwarded headers can make an application generate internal URLs. Compare the custom block with the installed iRedMail template rather than adding arbitrary rewrite rules.
Roundcube works, but mail clients cannot send or receive
Webmail uses HTTP; SMTP and IMAP do not. Test 587 and 993 independently, confirm their firewall exposure and certificates, and decide whether those protocols are direct iRedMail services or are being handled by NGINX’s mail proxy. A working /mail URL provides no evidence that either protocol is reachable.
Browsers warn about the certificate
Replace the self-signed certificate with a trusted certificate containing the exact hostname users open. Serve the complete certificate chain, reload NGINX after renewal, and retest from a client without a stored exception.
A generated configuration disappears after an update
Keep custom changes in the supported template or site-override location and retain a copy of the intended server block. Recheck enabled-site symlinks and rerun the syntax check after each iRedMail or NGINX upgrade.
Only IPv6 users see an error
Check the AAAA record, the IPv6 listen directive and the IPv6 firewall path. If IPv6 is not ready, remove the AAAA record rather than directing clients to an address where NGINX or the certificate is absent.
SOGo appears but live functions fail
Verify that the SOGo-specific template and any required connection upgrades are present. A generic root proxy can render a page while omitting application-specific routing, path handling or WebSocket requirements. Compare the active block with the generated SOGo configuration before adding manual rewrites.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Production security checklist
- Expose only 80/443 for web and only the mail ports your deployment needs.
- Keep databases, LDAP and application backends private, as in the default iRedMail layout.
- Use a publicly trusted certificate and automate or schedule renewal before expiry.
- Preserve the public host, client address and forwarded scheme for correct redirects and useful logs.
- Do not publish administration or monitoring paths unless there is a specific access-control plan.
- Test webmail, SMTP submission, IMAP and POP3 as separate services after every network or certificate change.
- Document which host owns each port so a later package update cannot create a listener collision.
Limit administrative access to the paths and networks that genuinely need it. In particular, publishing /iredadmin or /netdata on the same unrestricted hostname expands the exposed surface beyond ordinary webmail. If those paths must be public, apply the access controls supported by your deployment and verify them after every template regeneration.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesFrequently asked questions
Can NGINX proxy Roundcube and SOGo on the same hostname?
Yes. Preserve the documented /mail and /SOGo paths and route them through the HTTP server. Use the application-specific iRedMail templates when possible so aliases, redirects and application requirements remain intact.
Do I need NGINX in front of SMTP, IMAP or POP3?
No. If the normal iRedMail listeners meet your network design, leave those protocols on their documented ports. Add NGINX mail proxying only when you need a single endpoint or another deliberate routing boundary.
Which port should new users configure for sending mail?
Use authenticated SMTP submission on port 587. iRedMail documents port 465 as deprecated, so it should not be the default for a new configuration.
Can I forward HTTPS to iRedMail’s existing port 443?
Not safely by default on the same host. If NGINX owns public 443, the backend must use a private listener, or NGINX must run on a different host. Otherwise the proxy can loop back to itself or compete for the same socket.
Is a self-signed certificate acceptable?
It may be useful for a controlled internal test, but it is unsuitable for a public webmail URL. Use a trusted certificate, include the complete chain, cover every published hostname and reload NGINX after renewal.
Why does a working webmail page not prove mail-client access?
Roundcube and SOGo use HTTP(S), while mail clients use SMTP, IMAP or POP3. Test 587, 993 and 995 independently, and confirm whether each is direct or handled by the separate NGINX mail {} configuration.
Final decision
For most installations, the dependable pattern is NGINX terminating trusted TLS on 443, redirecting 80 to HTTPS, and forwarding the documented iRedMail web paths to a private backend listener. Use iRedMail’s generated templates when NGINX is installed on the mail server. Treat SMTP, IMAP and POP3 as a separate mail-proxy project—or leave them on their normal iRedMail ports—and never try to handle them inside an HTTP location block.
Frequently Asked Questions
Can NGINX proxy Roundcube and SOGo on one hostname?
Yes. Route the documented /mail and /SOGo paths through the HTTPS server and retain the corresponding iRedMail application templates.
Recommended Free Tools
Which port should users use for SMTP submission?
Port 587. iRedMail marks port 465 as deprecated for new submission deployments.
Can I proxy to iRedMail on port 443 on the same server?
Avoid it unless the backend has been moved to a private listener. Otherwise NGINX can loop to itself or collide with the public listener.
Does a working Roundcube page prove IMAP and SMTP work?
No. Webmail uses HTTP(S); test SMTP on 587 and encrypted IMAP on 993 separately, plus 995 if POP3 is offered.
Is the default iRedMail certificate suitable for public webmail?
No. The default template is self-signed. Install a trusted certificate covering every public hostname and reload NGINX after renewal.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →The Bottom Line
Use NGINX as the public HTTPS edge, keep iRedMail web services on a private listener, and preserve the documented application paths or generated templates. Expose only the ports you need, use a trusted certificate, and configure SMTP, IMAP and POP3 separately from HTTP proxying.
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.
