InternalDummyConnection

Requests From the Server to Itself

When the Apache HTTP Server manages its child processes, it needs a way to wake up processes that are listening for new connections. To do this, it sends a simple HTTP request back to itself. This request will appear in the access_log file with the remote address set to the loop-back interface (typically 127.0.0.1 or ::1 if IPv6 is configured). If you log the User-Agent string (as in the combined log format), you will see the server signature followed by "(internal dummy connection)" on non-SSL servers. During certain periods you may see up to one such request for each httpd child process.

These requests are perfectly normal and you do not, in general, need to worry about them. They can simply be ignored.

If you wish to exclude them from your log, you can use normal conditional-logging techniques. For example, to omit all requests from the loopback interface from your logs, you can use


SetEnvIf Remote_Addr "127\.0\.0\.1" loopback
and then add env=!loopback to the end of your CustomLog directive.

In 2.2.6 and earlier, in certain configurations, these requests may hit a heavy-weight dynamic web page and cause unnecessary load on the server. You can avoid this by using mod_rewrite to respond with a redirect when accessed with that specific User-Agent or IP address.

SSL Considerations

The internal dummy connections are not capable of speaking SSL. Thus, on servers with SSL enabled, these requests may generate noise in the server error log similar to the following:

[info] [client ::1] Connection to child 6 established (server localhost:443)
[info] Seeding PRNG with 656 bytes of entropy
[info] [client ::1] SSL library error 1 in handshake (server localhost:443)
[info] SSL Library Error: 336027900 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol speaking not SSL to HTTPS port!?
[info] [client ::1] Connection closed to child 6 with abortive shutdown (server localhost:443)
You can work around this by ensuring that the last Listen directive in your server configuration is not using SSL. In a typical setup, this would mean that "Listen 443" would come before "Listen 80".

This workaround should cause the internal dummy connections to be made to the non-SSL port, where you can optionally filter them out using the suggestions above.

In a future release, the server will attempt to connect to a non-SSL port by default. This change has been committed to svn, but not yet released (as of this writing).