Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a httpd.conf file that was accidentally changed to have the port number the server listens on changed to a number higher than 65535. When HTTPD reads this configuration file what does it do? Does it fall back to port 80?

share|improve this question
It depends on which HTTPd it is. – Hello71 Feb 9 '11 at 2:18
up vote 5 down vote accepted

It depends on the configuration. You can define multiple ports to listen on, in which case it will attempt to bind to all of them. Think of the application startup as a multiple step process. In it's most basic form the process would look like this:

  1. Read the config file, checking for errors
  2. Attempt to bind to the specified port
  3. Listen for connections

If you give it an unusable, but existing, port, then httpd would hit step 2 and fail. The application would fail to completely start, and would not fail down to port 80.

In the case where you presented a non-port, that is text, negative number, or number higher than 65535, then the config would be considered invalid, and httpd would die at 1.

share|improve this answer
It would just fail to start because of the bad config. It wouldn't fail down to port 80, because you havn't configured it to start on 80. However, even if you did add a second 'Listen 80' line, the bad port error would still prevent start up. – CK. Jun 1 '09 at 14:13
I screwed up and focused on the wrong failure path. Fixed :) – Scott Pack Jun 1 '09 at 14:19

One way would be to try it yourself, and use

netstat -lptn
to see what port httpd is listening on.

share|improve this answer

If you set the port higher than 65535, say for example 65536, it will give a syntax error saying "Invalid Address or Port".

share|improve this answer

A lot depends on the specific server software you're using.

You would expect the software to throw an error over an illegal port number but that is not necessarily the case; some software will happily accept whatever you hand it, resulting in very odd behavior.

Here's the issue: The port number is an unsigned 16-bit value (0 - 65535) and in some situations, applications will accept larger numbers but only use the lower 16 bits. This has lead to baffling cases where a startup script specifies a port of (say) 90000 and the application is found listening on port 24464 (90000 mod 65536 = 24464)

I documented a similar incident back in the Feb 2002 issue of SysAdmin Magazine in "Increasing Reliability Through Forensic Operations" (copy) Ideally, these things should never happen but between naive software and developers ignorant of the specifics of the underlying network (i.e. range of legitimate ports) one still needs to guard against such 'impossible' incidents. My preferred approach is to work with developers to make sure their code is ops-friendly but often ops and development aren't on the best of terms.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.