ProxyPassMatch or RewriteRules that reference Unix Domain Sockets do not work if unix: is followed by exactly two slashes. Any other number (including zero, resulting in a path relative to the ServerRoot) appears to work. If two slashes are used (as in "unix://"), the first path component is removed. For example, the following two methods to specify an FCGI proxy with unix domain sockets RewriteRule ^\/\/?test.fit$ unix://home/canavan/foo/run/php-fpm.sock|fcgi://localhost//home/canavan/foo/htdocs/engine/test.fit [P,L] ProxyPassMatch ^/(.*)$ "unix://home/canavan/foo/run/php-fpm.sock|fcgi://localhost//home/canavan/foo/testhost/staticwww" result in 503 errors and a message in the error log as follows: [Mon Jun 01 11:12:45.124529 2015] [proxy:debug] [pid 13534:tid 139897419593472] proxy_util.c(2226): [client 127.0.0.1:47978] AH02545: fcgi: has determined UDS as /canavan/foo/run/php-fpm.sock
This is not a bug. General qualified URI scheme is: <scheme>:[ "//" [ <hostname> ] ] <path> Thus, protocol:something - local relative path (implementation-dependent, do NOT rely on this functionality); protocol:/something - local absolute path; protocol://something - unknown path on remote host "something" (commonly considered equivalent to "protocol://something/", i.e. root path on "something" host); protocol:///something - absolute path on unnamed(=local) host (also often seen the more explicit form "protocol://./something"; since FQDN name ends in a dot, a lone dot represents an empty name).
I would argue that the (optional) authority part of the URI is obviously not useful for the unix: scheme, and thus unix:/foo and unix://foo should be equivalent. Alternatively, apachectl configtest should reject any configuration that references unix: URIs with an authority.