If Tomcat stopped responding after you edited server.xml, check these four things in order: the running instance is using the file you changed, the HTTP connector port is free, Tomcat was restarted, and the client is requesting the new host:port URL. A port change does not alter your web application’s context path. If the socket works but the app returns 404, troubleshoot deployment and the URL path instead of changing the port again.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Start with the shortest recovery path
Use this sequence before changing any other Tomcat setting. It separates configuration mistakes from network and application problems.
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Find the
server.xmlbelonging to the Tomcat instance that is actually running. - Confirm that you edited the HTTP or HTTPS
Connector, not the outerServershutdown port. - Choose a port that no other process or Tomcat instance is using on the same IP address.
- Stop and start that exact Tomcat service, container, or
CATALINA_BASEinstance. - Request the new URL, for example
http://localhost:1977/if the connector changed from 8080 to 1977. - If the port accepts a connection but the application fails, verify the application’s context path and deployment state.
- If local access works but another machine cannot connect, investigate firewall, security-group, proxy, container publishing, and bind-address settings.
Do not expose Tomcat’s administrative or shutdown port as a workaround for an unreachable HTTP endpoint.
Confirm which Tomcat configuration is active
The most common cause of an apparently ignored edit is changing a different installation from the one serving requests. A single installation often uses $CATALINA_HOME/conf/server.xml. A service with separate instance data normally uses the active instance’s $CATALINA_BASE/conf/server.xml. In a multi-instance installation, each CATALINA_BASE can have its own ports and deployed applications.
#1 Best Overall
Identify the process and its instance
- Check the service definition, startup script, container configuration, or process environment for
CATALINA_BASEandCATALINA_HOME. - Inspect the Tomcat process command line and environment rather than assuming the first installation directory you remember is active.
- Open the
conf/server.xmlunder that active base directory. Editing a copy in another user’s home directory, an old unpacked archive, or a development checkout has no effect on the running service. - After restarting, inspect the same instance’s logs. A startup message from a different base directory is evidence that you restarted the wrong instance.
Tomcat reads server.xml during startup. Saving the file does not make an already-running process adopt the new connector value, and the file cannot be reloaded as a substitute for restarting Tomcat.
Edit the HTTP Connector, not the shutdown port
In a typical configuration, the client-facing HTTP connector looks similar to this:
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 reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />The port attribute on this Connector is the TCP port on which Tomcat creates its server socket and waits for HTTP connections. Replace only that value with an unused port, preserving the rest of the connector unless you have a separate reason to change it.
Port 8080 is Tomcat’s usual HTTP default. It is a configuration default, not a requirement: any suitable unused port can be selected. Apache’s Tomcat startup guidance states: “Change it to a port that isn’t in use, and is greater than 1024, as ports less than or equal to 1024 require superuser access to bind under UNIX.” On Unix-like systems, binding to a port at or below 1024 generally requires the process to have the necessary elevated privilege. Choosing a higher port avoids that requirement for ordinary installations.
Do not confuse the three port settings
| Setting | Where it appears | Purpose | What to test |
|---|---|---|---|
| HTTP connector | <Connector port="..." protocol="HTTP/1.1"> |
Unencrypted client HTTP traffic | http://hostname:port/ |
| HTTPS connector | A connector configured with SSL/TLS attributes | Encrypted client HTTPS traffic | https://hostname:port/ |
| Server shutdown port | The port attribute on the outer <Server> element |
Receives Tomcat’s shutdown command; it is not a browser port | Do not use it as the web URL |
Changing the outer Server port will not make the HTTP endpoint move. Conversely, changing an HTTP connector does not change the shutdown listener. Keep those values distinct, especially when several Tomcat instances share one host.
Choose a port that is actually available
Only one server application can listen on a particular port and IP address at a time. A second Tomcat instance, a web server, a development tool, or an unrelated service can therefore prevent the connector from binding. A failed bind usually appears in the startup log with wording such as Address already in use, BindException, or a connector-initialization failure.
Free tools Windows power users keep installed
One-click scans. No signup required.
Inspect the selected port
Use the normal socket-inspection utility for the operating system hosting Tomcat. Replace 1977 in these examples with the port you selected:
| Platform | Diagnostic examples | What the result tells you |
|---|---|---|
| Linux and other Unix-like systems | ss -ltnp | grep ':1977'sudo lsof -nP -iTCP:1977 -sTCP:LISTEN |
Shows a listening process, its address, and often its PID. |
| Windows | netstat -ano | findstr :1977PowerShell: Get-NetTCPConnection -LocalPort 1977 |
Shows the listener; map a PID to a process before stopping anything. |
A listener on 127.0.0.1:1977 does not necessarily conflict with a listener on a different address, while a wildcard listener such as 0.0.0.0:1977 can claim the port for all IPv4 interfaces. Check the address as well as the number when diagnosing a collision.
Resolve a collision safely
- If another application owns the port, stop that application only if you know it is safe, or select another unused connector port.
- If a second Tomcat instance owns it, compare both instances’ HTTP, HTTPS, and shutdown values. Give each instance a unique set of listeners.
- If a previous Tomcat process did not exit cleanly, verify that it is gone before starting a replacement. Do not repeatedly launch additional copies until one happens to work.
- After changing the value, save the file and confirm that the startup log reports successful connector initialization rather than only a successful JVM launch.
Restart the same instance you edited
Tomcat applies a server.xml connector change on startup. Restart the service, container, or process associated with the active CATALINA_BASE; restarting a different installation leaves the original listener unchanged.
- Stop Tomcat using the mechanism that normally manages it: a service manager, container restart, vendor script, or the installation’s standard shutdown/startup scripts.
- Wait for the old Java process and its listeners to disappear. If the old port remains occupied, investigate before starting another copy.
- Start the same managed instance again.
- Read the startup log for connector bind errors, deployment failures, and the expected base directory.
- Confirm the new listener with a local request or a socket-inspection command.
Do not treat a process that merely remains in the process list as proof that the new configuration loaded. A service can report that Java started while one connector failed to initialize; the log and an actual socket test are authoritative.
Recommended Free Tools
Use the new host and port in every client
After changing 8080 to 1977, the HTTP address is, for example, http://localhost:1977/. Use the server’s real hostname or IP address when the client is remote. A browser bookmark, API client, health check, reverse proxy, load balancer, or firewall rule that still targets 8080 will make a healthy Tomcat instance appear offline.
Test locally before testing remotely
- From the Tomcat host, request
http://127.0.0.1:1977/orhttp://localhost:1977/. - If that works, request the host’s intended interface address from the same machine, because a connector may be bound only to loopback.
- From a second machine, use the server’s DNS name or reachable IP and the new port.
- Update clients and monitoring systems only after the local listener and application path are confirmed.
“Connection refused” generally means no process is accepting the connection on that address and port, or a network device is actively rejecting it. A timeout more often points to a firewall or routing path, although the exact behavior depends on the network. In both cases, first establish whether a local request succeeds.
Handle HTTPS and redirectPort changes correctly
HTTP and HTTPS connectors are separate sockets. If you changed the secure connector’s port, test with https:// and the new secure number; an HTTP request to that number is not an equivalent test.
The non-secure connector commonly contains a redirectPort attribute. That value tells Tomcat where a request requiring confidentiality should be redirected. When the HTTPS connector moves, review the non-SSL connector’s redirectPort as well. Apache’s SSL guidance specifically calls for updating this pairing and restarting Tomcat when the secure port changes.
| Change made | Values to review | Validation |
|---|---|---|
| HTTP only | HTTP connector port |
Request the new http:// URL. |
| HTTPS only | SSL connector port; any HTTP connector redirectPort that should point to it |
Request the new https:// URL and test an HTTP-to-HTTPS redirect if used. |
| Both endpoints | Both connector ports and their redirect relationship | Test each protocol independently after restart. |
A certificate warning, TLS handshake error, or redirect loop is a different failure axis from an HTTP bind failure. Once the secure socket accepts connections, troubleshoot certificates, protocol settings, and redirect behavior separately.
When Tomcat answers but the application does not
A successful TCP connection or the Tomcat welcome page proves that a connector is reachable; it does not prove that the requested web application exists at the path you used. Changing a port does not rename a deployed application or move it to the root path.
Check the context path
If the deployed archive is named myapp.war, the usual request path is /myapp/, so the complete URL might be http://localhost:1977/myapp/. Requesting only / can legitimately return the default page or a 404 while the application itself is healthy.
- Check the deployed WAR or exploded directory name and any explicit context configuration.
- Confirm that the application appears in the startup log without deployment or initialization errors.
- Request the exact context path, including capitalization where the operating system and deployment layout make it significant.
- Verify that the proxy or load balancer preserves the path and sends traffic to the new backend port.
Tomcat’s Context configuration is separate from the connector. Many deployments keep per-host or application context definitions outside server.xml; do not rewrite those definitions merely because the listener changed. A server.xml edit still requires a restart, but the application URL path remains a deployment decision.
Rank #4
Distinguish common responses
| Observed result | Likely meaning | Next check |
|---|---|---|
| Connection refused | No listener at that address and port, or an active reject on the path | Active connector, restart, port ownership, and address. |
| Timeout from another machine; local request works | Network policy or routing issue | Firewall, security group, container publishing, proxy, and bind address. |
| Tomcat landing page | Connector and basic request path work | Use the application’s context path and inspect deployment logs. |
| 404 for the application path | Wrong context, undeployed application, or proxy path rewrite | WAR/context name, deployment state, and proxy configuration. |
| HTTP redirects incorrectly or secure URL fails | HTTPS connector and redirectPort do not match, or TLS has its own error |
Review both connectors, restart, then test TLS separately. |
When local access works but remote access fails
Once a local request succeeds on the new port, Tomcat itself may be functioning correctly. The remaining controls are outside the connector’s numeric port value.
- Bind address: A connector restricted to loopback accepts requests from the Tomcat host but not from other machines. Check the connector’s address or the host’s interface binding.
- Host firewall: Permit the new application port in the operating system firewall while leaving the shutdown port protected.
- Cloud security group or network ACL: Update the inbound rule for the new port and the intended source ranges.
- Container publishing: If Tomcat runs in a container, publish the host port to the container port and update orchestration or compose configuration. Changing the file inside the image does not automatically change the host mapping.
- Reverse proxy or load balancer: Change its upstream target and health check from the old port, then verify that path and protocol settings remain correct.
- DNS and client caches: Ensure the remote client resolves the intended host and is not using a stale endpoint.
Test from the server first, then across the network boundary. This order prevents a firewall investigation from obscuring a connector that never started.
Account for multiple Tomcat instances and portOffset
Running several instances on one host requires unique listeners for every instance. Compare each instance’s HTTP connector, HTTPS connector, and outer shutdown port. A conflict in any one of them can stop one instance while another continues to serve traffic.
Tomcat also supports portOffset in the server configuration. An offset can shift the server port and nested connector ports for an instance, which is useful for repeatable multi-instance layouts but can make the effective listening number differ from the literal connector value you expected. When diagnosing an overlap, calculate the effective ports and inspect the actual sockets rather than comparing only the text in one file.
Safe multi-instance checklist
- Record the intended HTTP, HTTPS, and shutdown values for every
CATALINA_BASE. - Check whether a
portOffsetchanges those effective values. - Start instances one at a time and verify each listener before starting the next.
- Keep monitoring, proxy, and firewall rules aligned with the effective ports.
Read the startup log for the decisive error
The first connector-related error during startup usually narrows the problem faster than repeated browser tests. Search the active instance’s logs for the selected port, bind, Address already in use, connector initialization, SSL, and deployment messages.
- A bind or address-in-use message points to port ownership or an address conflict.
- An error-free startup followed by a refused local connection suggests that you edited or restarted the wrong instance, tested the wrong address, or the connector was disabled or commented out.
- A successful connector followed by application deployment errors means the port is working and the application needs separate remediation.
- An SSL initialization error affects the HTTPS connector; test the HTTP connector independently if one exists.
Preserve the exact timestamp and instance directory when comparing logs. On hosts with several Java services, a log from another process can otherwise lead you to “fix” a configuration Tomcat never loaded.
Common mistakes and their fixes
| Mistake | Why it fails | Corrective action |
|---|---|---|
Editing a copy of server.xml |
The running process reads another CATALINA_BASE. |
Trace the managed process and edit its active configuration. |
Changing the outer Server port |
That listener is for shutdown, not browser traffic. | Change the client-facing connector’s port. |
| Choosing a port already in use | The operating system permits only one listener per port and IP. | Identify the owner and stop it safely or choose another port. |
| Saving without restarting | Tomcat does not apply this connector edit to the running process. | Restart the same service or instance and read its startup log. |
| Continuing to use the old URL | The client still contacts the old socket. | Update the URL, bookmarks, probes, proxies, and firewall rules. |
Testing / when the app is under a context |
The connector works, but the requested path is wrong. | Use the deployed context path, such as /myapp/. |
| Opening the shutdown port to remote users | It does not serve HTTP and creates an unnecessary administrative exposure. | Expose only the intended application connector and protect management interfaces. |
A repeatable port-change procedure
For future changes, use a change record that captures the old and new values, the instance, and every dependent system.
- Record the active
CATALINA_BASE, current HTTP and HTTPS ports, shutdown port, bind address, and anyportOffset. - Check the proposed port on the relevant address and document the process check result.
- Edit the active connector’s
portattribute, and updateredirectPortwhen the secure endpoint is moving. - Restart the same managed instance.
- Confirm startup logs and the listening socket.
- Test the new protocol, hostname, port, and application context locally.
- Update reverse proxies, health checks, firewalls, security groups, container mappings, bookmarks, and API clients.
- Test from the real remote network and verify that the old endpoint is no longer being used unintentionally.
Keep the previous working value documented until the new endpoint has passed local, application, and remote checks. If the change fails, restoring the old connector value and restarting the same instance provides a controlled rollback, provided the old port is still available.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsQuick Recap
Symptom-based decision table
| Symptom | Most likely axis | Evidence-led action |
|---|---|---|
| Tomcat fails during startup with bind or address-in-use text | Port ownership | Select an unused connector port or stop the conflicting process. |
| Tomcat starts, but the browser refuses the old URL | Client URL | Use the new port in the URL and update dependent clients. |
| Local request works; remote request fails | Network path or firewall | Check bind address, firewall, security group, proxy, and container publishing. |
| HTTP works; HTTPS redirect or secure URL fails | Connector and redirectPort pairing |
Review the secure connector and redirect target, then restart. |
| Tomcat landing page works; application returns 404 | Context path or deployment | Verify the WAR/context name, deployment logs, and proxy path. |
| One instance works while another cannot start | Overlapping listeners or offset | Compare all effective Server and Connector ports across instances. |
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.
