Connection Refused

From Mac OS X Server FAQ

One of the more common errors when attempting to access a network service is "connection refused". This page will provide general hints for diagnosing and troubleshooting this problem, which can occur with just about any network service. Generally, there are two areas on which to concentrate: service troubleshooting and network troubleshooting. Before assuming something is broken, it might be a good idea to verify network settings on the server and client; make sure you are attempting to connect to the correct IP or hostname.

Troubleshooting the service

We'll start the diagnosis on the server itself with the terminal command:

netstat -na | grep LISTEN

This displays all active 'listening' socks. Try to find the entry for your service's port. If you're not sure which port that may be, refer to this page on network service ports. If you don't see your service's entry, it could be that the service is not running. As an example, shown below is the entry for the ftp server:

tcp46      0      0  *.21                   *.*                    LISTEN

If you do not see a listener entry for the service in question, attempt to verify that the service is running at all. This can usually be accomplished by searching a list of processes for the service's name. It is also useful to verify with <code>serveradmin</code> that the service is enabled. Below is a table of process names, service name according to <code>serveradmin</code>, and a short description for each server process that a user is likely to interact with directly using a client program. To determine if the given service is running:

ps auxwww | grep {Process Name}

If there are results (other than the grep process), then the service is running (it may not be functional, but it is at least running). Use serveradmin to check if a service is enabled as follows:

sudo serveradmin status {Server Admin service name}

Process Name	Server Admin Server Name	Description
httpd	web	Apache web service
AppleFileServer	afp	AppleShare service
AppleVNCServer	n/a	Remote Desktop service (client)
vpnd	vpn	VPN Service
QuickTimeStreamingServer	qtss	QuickTiem Streaming Server
smbd	smb	Windows file service
pickup	mail	Part of the mail service (pickup does not accept client connections, but suggests that mail is enabled)

Here's a list of server processes you may not see in a process list, because they are launched only on demand by xinetd (again, these are only services that a user is likely to interact with directly; to see a full list of services managed by xinetd, do service --list).

Process Name	Server Admin Service Name	Description
sshd	n/a	Secure Shell service
ftpd	ftp	File Transfer Protocol service

For example, to see if the web server is running:

ps auxww | grep httpd

or

sudo serveradmin status web

Also note that although service daemons managaed by xinetd only run on demand, xinetd still opens a listening socket on behalf of that service, so it would still show up with netstat;.

If the service is not running after attempting to enable it, there may be a service configuration problem preventing it from starting. Check the logs for the specific service (this is usually a good time to jack up the log verbosity), also check the main system log (/var/log/system.log). Because every service is different, service-specific troubleshooting is beyond the scope of this faq entry.

If the service *is* running, but you still cannot connect from a remote client, and you have verified that the service is listening by using netstat as discussed above, find out which of your servers IP addresses are considered valid entry points for this service, as discussed here. Verify that you are trying to access the service using the correct IP address. If it is only accessible from localhost, refer back to the service's configuration. If the service *should* be listening for connections on any IP address and still does not answer remotely, try to access the service locally. This is not always easy, but here are some suggestions:

Testing the web service using a command line http client:

curl http://your.server.name

Testing the ftp service:

ftp localhost

Testing the windows file service:

smbclient -L localhost

telnet makes a good general purpose test client, as it can easily be made to open connections to arbitrary (tcp) ports. Because most service daemons use textual application protocols, it is often possible to not only see that the service answers, but also to interact with it directly. To test the afp service (a good candidate, since afp doesn't allow self-mounting), we can use telnet by specifying the port number for afp after the hostname (localost):

core[~]telnet localhost 548
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

If you see "Connected to localhost", somebody picked up the phone on port 548. Type control-], then quit to exit the telnet session

If the telnet session does not open, the service is probably not listening. If you cannot connect locally, but should be able to, that is probably a service specific problem, but also see the section below about checking the OS X Server firewall. If you can connect locally, but not remotely (and should be able to, based onnetstat output, move on to....