Troubleshooting Chrome’s Failure to Recognize Nginx HTTP/2 Server Despite Proper Configuration


17 views

You've configured Nginx with HTTP/2 support following Digital Ocean's guide, and external verification tools confirm it's working:

$ curl -I --http2 https://www.example.com
HTTP/2 200 
server: nginx/1.10.0 (Ubuntu)

Yet Chrome's DevTools stubbornly shows:

NAME             METHOD  STATUS  PROTOCOL
shell.js?v=xx..    GET    200     http/1.1

First, let's verify HTTP/2 support through Chrome's internal tools:

chrome://net-internals/#http2

Check for your domain in the list of HTTP/2-enabled sites. If present but still showing HTTP/1.1 in DevTools, we need deeper investigation.

1. Mixed Content Issues

Chrome may downgrade to HTTP/1.1 if your page loads any insecure resources:

// Check console for warnings like:
Mixed Content: The page was loaded over HTTPS, 
but requested an insecure resource 'http://example.com/insecure.js'

2. Connection Reuse Problems

Try forcing a fresh connection in Chrome DevTools:

  1. Open DevTools (F12)
  2. Go to Network tab
  3. Check "Disable cache"
  4. Right-click the request list and select "Clear browser cache"

3. Nginx Configuration Gotchas

Ensure your SSL configuration includes modern protocols:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256...';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

For Safari 10.0.1 verification:

  1. Enable Develop menu (Preferences → Advanced)
  2. Open Web Inspector (Develop → Show Web Inspector)
  3. Check the Network tab's protocol column

Alternatively, use this terminal command:

nscurl --ats-diagnostics --verbose https://example.com

Capture network traffic to verify the actual protocol negotiation:

sudo tcpdump -i any -s 0 -A 'tcp port 443 and host example.com' -w capture.pcap

Analyze with Wireshark, looking for:

  • TLS ALPN extension in ClientHello
  • Server's protocol selection in ServerHello

Here's a complete HTTP/2-ready configuration:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    
    server_name example.com;
    
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    
    # Modern SSL configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256...';
    ssl_prefer_server_ciphers on;
    
    # HTTP/2 optimization
    http2_push_preload on;
    http2_max_concurrent_streams 128;
    
    # Other directives...
}

When Chrome DevTools persistently shows HTTP/1.1 while external tools confirm HTTP/2 functionality, we need to examine several technical aspects:

# Verify HTTP/2 support via command line
curl -v --http2 -s -o /dev/null https://yourdomain.com 2>&1 | grep -i "HTTP/2"

Modern Chrome versions (v54+) implement strict protocol selection criteria. The browser might fall back to HTTP/1.1 if:

  • SSL/TLS cipher suites aren't optimally configured
  • Certificate chain contains intermediate issues
  • ALPN negotiation fails silently

Ensure your nginx.conf contains these critical elements:

server {
    listen 443 ssl http2;
    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    # Force HTTP/2 prioritization
    http2_push_preload on;
}

Access these hidden Chrome features for deeper inspection:

  1. Navigate to chrome://net-internals/#http2
  2. Check chrome://net-export/ for session logs
  3. Use chrome://flags/#enable-http2-grease-setting for experimental support

For Safari 10.0.1 diagnostics:

# Enable Develop menu first, then:
1. Open Web Inspector (Option+Command+I)
2. Navigate to Network tab
3. Reload page while holding Option key
4. Check protocol column (enable via right-click header)

These frequently overlooked issues can cause protocol downgrade:

  • Mixed content warnings triggering fallback
  • Incorrect listen directive order (http2 must come after ssl)
  • Outdated nginx modules needing recompilation
  • Reverse proxy configurations interfering with ALPN

For conclusive testing, run these diagnostic commands:

# Check OpenSSL ALPN support
openssl s_client -alpn h2 -connect yourdomain.com:443 | grep "ALPN"

# Verify NPN support (legacy fallback)
openssl s_client -nextprotoneg h2 -connect yourdomain.com:443

# Test with HTTP/2-specific tools
nghttp -v -n --no-dep https://yourdomain.com