The classic symptom: your custom domain (like test.dev) resolves to 127.0.0.1 via /etc/hosts, ping works, but HTTP requests fail with "Connection refused". This indicates a network-layer connectivity issue before Apache even sees the request.

# Confirm DNS resolution
host test.dev
# Expected output: test.dev has address 127.0.0.1

# Test raw TCP connectivity
nc -zv test.dev 80
# If this fails, we have a port-level blockage

Check if Apache is actually bound to all interfaces on port 80:

# Check listening ports
sudo lsof -iTCP -sTCP:LISTEN -P | grep httpd
# Should show entries like: *:http (LISTEN)

# Alternative check
ss -tulpn | grep 80
# Should show Apache processes listening on 0.0.0.0:80

If missing, ensure httpd.conf contains:

Listen 80
<VirtualHost *:80>
    # Your configuration
</VirtualHost>

Modern systems often block ports by default. For macOS:

# Check pf firewall status
sudo pfctl -s rules

# Temporarily disable for testing
sudo pfctl -d

For Linux systems:

sudo iptables -L -n -v | grep 80
sudo ufw status

Apache selects the first matching VirtualHost when no exact ServerName match exists. Test with:

curl -H "Host: test.dev" http://localhost/

For proper debugging, enable detailed logging:

LogLevel debug
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log combined

Here's a working template for development environments:

<VirtualHost *:80>
    ServerName test.dev
    ServerAlias www.test.dev
    DocumentRoot "/path/to/your/project"
    ErrorLog "/private/var/log/apache2/test.dev-error_log"
    CustomLog "/private/var/log/apache2/test.dev-access_log" common
    
    <Directory "/path/to/your/project">
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

When all else fails, inspect the full network path:

# Check route to host
route get test.dev

# Test with different clients
telnet 127.0.0.1 80
openssl s_client -connect test.dev:80 -debug

---

When configuring virtual hosts in Apache 2.4, receiving a "Connection refused" error for a specific domain while others work perfectly indicates a fundamental network or configuration problem. Let's break down what's happening when you encounter:

curl: (7) Failed to connect to test.dev port 80: Connection refused

First, verify basic network connectivity and DNS resolution:

# Ping test (should resolve to 127.0.0.1)
ping test.dev

# Check if port 80 is actually listening
netstat -tuln | grep 80
# Or alternative command:
lsof -i :80

Your virtual host configuration appears correct at first glance, but let's examine potential pitfalls:

# Main configuration check:
apachectl configtest

# Verify NameVirtualHost is set (though not strictly required in 2.4+):
grep -r "NameVirtualHost" /etc/apache2/

# Check for conflicting configurations:
grep -r "Listen" /etc/apache2/

Several subtle issues can cause this behavior:

• Missing ServerName directive in the main configuration
• Port conflicts with other services
• MacOS specific firewall settings
• Incorrect hosts file permissions

Try these diagnostic commands to pinpoint the issue:

# Check if Apache is binding to all interfaces
sudo netstat -plant | grep httpd

# Test raw TCP connection
telnet test.dev 80

# Verify using different tools
nc -zv test.dev 80
curl -v http://test.dev

On MacOS, additional factors come into play:

# Check native MacOS firewall
sudo pfctl -sr | grep "port 80"

# Verify Apache is properly enabled
sudo apachectl start
sudo apachectl status

Here's a complete working example for reference:

<VirtualHost *:80>
    ServerAdmin webmaster@test.dev
    DocumentRoot "/Users/username/Sites/test"
    ServerName test.dev
    ServerAlias www.test.dev
    ErrorLog "/private/var/log/apache2/test.dev-error_log"
    CustomLog "/private/var/log/apache2/test.dev-access_log" common

    <Directory "/Users/username/Sites/test">
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Follow this logical sequence when debugging:

1. Verify DNS resolution (/etc/hosts)
2. Check port accessibility (telnet/nc)
3. Inspect Apache error logs
4. Test with different browsers/curl
5. Check for IPV6 vs IPV4 issues

• Restart Apache after configuration changes
• Clear DNS cache (dscacheutil -flushcache on MacOS)
• Verify file permissions on document root
• Check for SELinux/apparmor on Linux systems