Hey there, let's tackle that ERR_SSL_PROTOCOL_ERROR you're seeing when first visiting forum.mypage.com. I've worked through plenty of multi-subdomain SSL setups with Nginx and Discourse, so let's break down the most likely fixes step by step.

This is usually the first place to look—misconfigured Nginx blocks are a common culprit.

• Make sure you have separate server blocks for HTTP (80) and HTTPS (443) for the forum subdomain:

  server {
      listen 80;
      server_name forum.mypage.com;
      # Redirect all HTTP traffic to HTTPS
      return 301 https://$server_name$request_uri;
  }
  
  server {
      listen 443 ssl http2;
      server_name forum.mypage.com;
  
      # Point to your Let's Encrypt certificate files
      ssl_certificate /etc/letsencrypt/live/forum.mypage.com/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/forum.mypage.com/privkey.pem;
  
      # Ensure you're using modern SSL protocols/ciphers
      ssl_protocols TLSv1.2 TLSv1.3;
      ssl_ciphers HIGH:!aNULL:!MD5;
  
      # Proxy traffic to your Discourse instance (adjust port if needed)
      location / {
          proxy_pass http://localhost:3000;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto $scheme;
      }
  }
  

• After editing, test the config with nginx -t to catch syntax errors, then reload Nginx: systemctl reload nginx

It's easy to accidentally generate a certificate that only includes the main domain or other subdomains.

• Run certbot certificates to list all your certificates. Look for an entry for forum.mypage.com—if it's missing, reissue the certificate with all subdomains:

  certbot certonly --nginx -d mypage.com -d blog.mypage.com -d forum.mypage.com
  

• Check file permissions on your certificate files to make sure Nginx can read them:

  ls -l /etc/letsencrypt/live/forum.mypage.com/
  

  The files should be readable by the www-data user (or whatever user Nginx runs as).

Discourse has its own internal settings that can clash with SSL if not set correctly.

• Open your Discourse app.yml file (usually at /var/discourse/containers/app.yml) and verify these env vars:

  env:
    DISCOURSE_HOSTNAME: forum.mypage.com
    DISCOURSE_PROTOCOL: https
    DISCOURSE_FORCE_HTTPS: true
  

• Save the file and restart Discourse to apply changes:

  cd /var/discourse && ./launcher restart app
  

If port 443 isn't open, browsers can't establish an SSL connection.

• Check your server's local firewall:

  ufw status
  

  Ensure there's a rule allowing 443/tcp. If not, add it: ufw allow 443/tcp
• Don't forget your VPS provider's cloud firewall (e.g., AWS Security Groups, DigitalOcean Firewalls)—make sure 443 is allowed there too.
• Test connectivity from the server itself with curl -v https://forum.mypage.com—this will show you if the SSL handshake works locally.

Even with a fresh browser, DNS propagation might not be complete, or local DNS cache could be stale.

• Run nslookup forum.mypage.com on your local machine and the server to confirm both resolve to the same VPS IP address.
• If you're using a CDN (like Cloudflare), temporarily disable it to rule out CDN-side SSL misconfigurations.

Use OpenSSL to get detailed error messages about what's failing during the handshake:

openssl s_client -connect forum.mypage.com:443

Look for lines like error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure—these will point to specific issues like protocol mismatches or invalid certificates.

Start with the Nginx config and certificate checks first—those are the most frequent offenders in multi-subdomain setups. If you hit a specific error during any of these steps, share the output and we can narrow it down further.

内容的提问来源于stack exchange，提问作者mDfRg