iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Godlike.Host offers hosted Minecraft Java servers with its own game panel, SFTP access and free DDoS protection, if you would rather not host it yourself.
Use a hostname such as map.example.com, point its DNS A record to your Minecraft server’s public IP, and place Nginx or Apache in front of Dynmap as a reverse proxy. First prove that Dynmap works at http://SERVER_IP:8123/ (or your configured port). The proxy then serves the map on normal web ports, so visitors use https://map.example.com/ without typing :8123. HTTPS is optional but can be added at the proxy with Certbot.
What linking a domain to Dynmap actually does
Dynmap includes its own web server. Its documented default listener is port 8123, so a direct address usually looks like http://SERVER_IP:8123/. A custom domain does not replace that internal service. Instead, DNS gives the server a memorable name and a reverse proxy accepts browser requests on ports 80 and 443, then forwards them to Dynmap on its internal port.
The resulting path is:
- Browser: requests
https://map.example.com/. - DNS: resolves
map.example.comto your server’s public IP. - Nginx or Apache: listens on the public web port and selects the matching hostname.
- Dynmap: continues listening on
localhost:8123(or another configured port).
This arrangement keeps Dynmap’s internal port as the upstream target while giving users a clean hostname, standard web ports and, when enabled, TLS encryption.
Requirements and decisions before you start
- A registered domain that you control, such as
example.com. - A Dynmap installation that is already running on a Minecraft server.
- Administrative access to the machine or host running Dynmap, or cooperation from the host administrator.
- A web server (Nginx or Apache) that can listen on ports 80 and, for HTTPS, 443.
- Permission to create DNS records and to open or forward the required ports through host firewalls, cloud security groups and home routers.
Check the Dynmap setting named webserver-port. The documented default is 8123. Shared Minecraft hosts sometimes restrict which ports are available; an administrator may need to assign a different port and restart the server. Use the actual configured value in every proxy and firewall rule.
For a self-hosted server behind a router, the selected Dynmap port must be reachable from the proxy machine. If the proxy runs on the same host, forwarding the internal Dynmap port to the public internet is usually unnecessary; expose only the proxy’s public ports. If the proxy is on another machine, allow that machine to reach Dynmap’s listening address and port.
Step 1: Prove Dynmap works directly
Do this before changing DNS or writing proxy rules. It separates a Dynmap problem from a DNS or web-server problem.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →- Find the server’s public IP address and the configured Dynmap port.
- From a browser, open
http://SERVER_IP:8123/, replacing8123when your configuration uses another port. - Confirm that the map loads and that the Dynmap log reports a successful web-server start.
- If the page does not load, fix Dynmap startup, binding, firewall or router port-forwarding issues first. Do not proceed to DNS or the reverse proxy until this direct test succeeds.
The Dynmap web server binds to the address specified in its configuration. A service bound only to an inaccessible interface will not be reachable by the proxy. On a same-machine setup, a proxy target of localhost works when Dynmap is listening on the local loopback interface; otherwise use the reachable address appropriate to your installation.
Step 2: Choose the hostname and create DNS
A subdomain keeps the map separate from a main website. The common choice is map.example.com, but any hostname you control can be used. The hostname in DNS, the proxy’s server_name (or Apache virtual host), and the TLS certificate name must match exactly.
| Address users visit | DNS record name in most registrar panels | Record value |
|---|---|---|
example.com |
@ (the zone apex) |
Your server’s public IP address |
map.example.com |
map |
Your server’s public IP address |
The Dynmap Nginx example explicitly uses an A record with host @ pointing to the server’s IP for a root domain. For a subdomain, enter the subdomain label (for example, map) in the registrar’s DNS interface. Registrar interfaces differ, so verify whether they expect only the label or the complete hostname.
Use an IPv4 A record when pointing to an IPv4 address. Do not enter http://, a port number or a path in the record value. DNS propagation depends on the provider and the record’s TTL; there is no universal propagation time. Check that the record resolves to the intended public IP before blaming the proxy.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Step 3: Configure Nginx as the reverse proxy
Nginx is a good choice when it is already part of your server stack. Create a server block for the exact hostname and forward requests to Dynmap’s internal web server.
server {
server_name map.example.com;
listen 80;
location / {
proxy_pass http://localhost:8123/;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}Replace map.example.com with the hostname users will enter and replace 8123 with Dynmap’s configured port. Keep the trailing slash in the documented proxy_pass value unless you have deliberately designed a different URL path.
Enable and validate the server block
- Save the server block in the location used by your Nginx installation for virtual hosts.
- Make sure the DNS record already points at this machine, or at least be prepared for the hostname to resolve there when testing.
- Run the configuration test:
sudo service nginx configtest. - Only after a successful test, restart or reload Nginx using your system’s normal service command.
- Open
http://map.example.com/. A successful response confirms that the hostname, DNS and proxy route reach Dynmap.
If your distribution reports that the service command is unavailable, use the equivalent Nginx service-management command provided by that operating system; the important requirement is to validate the configuration before restarting.
Step 4: Add HTTPS and remove :8123 from the public URL
To serve the map securely, obtain a certificate for the same hostname and configure the proxy to listen on port 443. The Dynmap Nginx guidance points administrators to Certbot for certificate setup. HTTP validation and ordinary HTTP access require port 80; HTTPS requires port 443. On a home router, forward those ports to the machine running Nginx.
After TLS is configured, users can visit https://map.example.com/. They omit :8123 because the browser connects to the proxy’s standard HTTPS port; Nginx still forwards internally to Dynmap’s configured port. The certificate belongs to the public hostname, not to localhost or the numeric Dynmap port.
- Ensure the DNS record resolves publicly before requesting a certificate.
- Allow port 80 if the certificate tool needs HTTP validation.
- Allow port 443 for encrypted visitors.
- Use the exact same hostname in DNS, Nginx and the certificate request.
Whether HTTP remains available or redirects to HTTPS depends on your proxy configuration. The essential requirement is that the HTTPS listener forwards to the same Dynmap upstream.
Apache configuration alternative
Use Apache instead of Nginx when Apache is already your site’s web server or your administrator is more familiar with its virtual-host configuration. On Debian or Ubuntu, the Dynmap Apache guidance requires the rewrite and proxy_http modules.
- Enable the required modules using your distribution’s Apache module tools.
- In the virtual host for
map.example.com, add:
ProxyRequests off
ProxyPass / "http://localhost:8123/"
ProxyPassReverse / "http://localhost:8123/"- Replace
8123if Dynmap uses another port. - Validate the Apache configuration before restarting the service.
- Restart Apache, then visit the domain over HTTP or HTTPS, depending on the listeners and certificate configuration you enabled.
ProxyRequests off is important: this setup is a reverse proxy for your Dynmap service, not a general-purpose forward proxy. The ProxyPassReverse directive lets Apache adjust upstream redirect responses so they remain usable through the public hostname.
Recommended Free Tools
Ports, binding and firewall rules
| Port | Role | When it must be reachable |
|---|---|---|
| Dynmap port (8123 by default) | Internal Dynmap web server | From the proxy host to Dynmap; shared hosts may assign another value |
| 80 | HTTP and commonly HTTP certificate validation | From visitors or certificate services to the proxy |
| 443 | HTTPS | From visitors to the proxy when using TLS |
Open the relevant ports in every layer that can block traffic: the operating-system firewall, a cloud security group, a hosting control panel and, for a home server, the router’s port-forwarding rules. A direct Dynmap test that works on the server itself but fails externally usually indicates a binding, firewall or router problem rather than DNS.
Do not assume that changing the public port changes Dynmap’s internal setting. The proxy can listen on 80 or 443 while Dynmap remains on 8123. If you intentionally change webserver-port, restart the Minecraft server and update the proxy target and any required firewall rule together.
Forwarded client IPs and trusted-proxies
When Dynmap is behind a proxy, the application may need to trust forwarded client-IP headers for IP-based username recognition. Dynmap’s configuration reference documents a trusted-proxies setting and shows loopback addresses as defaults. Configure it only when your deployment actually needs forwarded client-IP handling.
Trust only the proxy addresses that you administer. A broad trust rule can allow a client to supply a misleading forwarded address. If you do not use IP-based username recognition, leave this setting at its safe default rather than changing it merely because a proxy is present.
Free tools Windows power users keep installed
One-click scans. No signup required.
Choosing between common deployment patterns
| Approach | Advantages | Trade-offs and best use |
|---|---|---|
| Reverse proxy with Nginx | Preserves Dynmap’s live internal service, supports standard ports and TLS termination, and works well when Nginx already runs on the host. | Requires a valid server block, reachable upstream and correct firewall rules. |
| Reverse proxy with Apache | Uses an existing Apache stack and the documented ProxyPass/ProxyPassReverse directives. |
Requires the proxy modules and a correctly matched virtual host. |
| Serve copied static web files through an external web server | Can fit a design where an external server serves files directly. | Copying files separates the public site from Dynmap’s internal service and can require an update process; reverse proxying is the clearer route when you want the running Dynmap service at a custom hostname. |
| Direct custom port | Fewest moving parts; visitors connect straight to Dynmap. | Users must include the port, such as http://map.example.com:8123/, and TLS, firewall and port-forwarding work are handled differently. It does not provide the clean standard-port URL. |
| HTTP only | Simple initial test and no certificate setup. | Traffic is not encrypted and visitors use an HTTP URL. |
| HTTPS at the proxy | Visitors use a standard encrypted URL and Dynmap’s internal port stays private to the proxy path. | Requires certificate issuance, DNS correctness and reachable ports 80/443 as applicable. |
Troubleshooting by symptom
The direct IP URL does not work
- Check the Dynmap log for a successful web-server start.
- Confirm the configured
webserver-port; do not assume it is still 8123 on a shared host. - Check which address Dynmap is bound to and test from the proxy host.
- Inspect host firewall rules and, for self-hosting, router port forwarding.
The hostname resolves to the wrong machine
- Inspect the DNS
Arecord and compare its value with the server’s current public IP. - Check whether you created the record at the correct DNS provider and used the right label:
@for the root host ormapformap.example.com. - Allow for provider-specific propagation and TTL behavior; there is no guaranteed global propagation interval.
Nginx or Apache returns a 502/Bad Gateway
- Confirm that Dynmap is running and listening on the configured port.
- From the proxy host, verify that the upstream target matches the documented default,
localhost:8123, or your replacement address and port. - Check whether a local firewall blocks the proxy-to-Dynmap connection.
- Re-run the Nginx configuration test or Apache validation and inspect the web-server error log.
The proxy serves the wrong site
- Make the proxy hostname exactly match the DNS hostname users visit.
- Check for another virtual host that catches the request first.
- Ensure the browser is not using a different spelling, alternate subdomain or stale bookmark.
HTTP works but HTTPS fails
- Confirm that port 443 is allowed through firewalls, security groups and routers.
- Check that the certificate covers the exact hostname, including the subdomain.
- Verify that the TLS virtual host forwards to the same Dynmap upstream as the working HTTP configuration.
- If certificate issuance fails, recheck public DNS and the availability of port 80 when HTTP validation is being used.
The map loads at the IP but not at the domain
This usually means the Dynmap service is healthy and the fault is in DNS, proxy selection or firewall exposure. Test in order: resolve the hostname, request the HTTP URL, inspect the proxy logs, and then test the upstream locally. Keeping those layers separate prevents repeated changes to a working Dynmap installation.
Operational checklist after the change
- Direct Dynmap URL works on the configured internal port.
- The DNS
Arecord points to the current public IP. - The proxy hostname exactly matches the DNS name.
- The proxy target uses the actual Dynmap port.
- Nginx or Apache configuration validation succeeds before restart.
- Port 80 is open when HTTP access or certificate validation requires it.
- Port 443 is open for HTTPS visitors.
- The certificate name matches the hostname users enter.
trusted-proxiesis changed only when forwarded client-IP handling is required.
Once these checks pass, the public address is simply the hostname, for example https://map.example.com/; Dynmap continues operating behind the proxy on its configured internal port.
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.
