GCP VM实例托管网站连接拒绝及无法SSH问题技术求助

Hey there, let's work through this step by step to get your site back online and fix that stubborn SSH problem—since you're new to GCP, I'll keep things clear and actionable, no jargon overload.

First: Fix the Stuck SSH Connection #

Since your new instance (using the same custom image) works fine for SSH, the issue isn't the image itself—it's specific to your original VM. Here's what to try first:

• Use the Serial Console to Bypass Network SSH
  This is a lifesaver when regular SSH fails because it connects directly to the VM's hardware console, no network required. To use it:

  1. Head to your GCP Console > Compute Engine > VM Instances
  2. Find your problematic instance, click the dropdown next to "Connect" > select "Connect to serial console"
  3. Once connected, you’ll see boot logs, error messages (like disk full errors), or maybe even a login prompt. If you get a prompt, use your instance’s credentials to log in directly.

• Check for Full Disk Errors (From Your df -h Screenshot)
  A full root disk is one of the most common causes of SSH and service failures. Scan your df -h output for any filesystem showing 100% usage:

  • If you can access the serial console, run sudo apt clean (for Debian/Ubuntu) to clear package caches, or delete large unused files (like old logs in /var/log/).
  • If you can’t get into the console, detach the disk from the broken instance, attach it to your working new instance, and clean up space from there.

• Verify the SSH Service Status
  If you log in via serial console, run sudo systemctl status sshd (for systemd-based systems) to check if the SSH service is running. If it’s failed, the error messages will tell you why—common issues include misconfigured sshd_config files or missing dependencies.

Next: Fix the Website "Connection Refused" Error #

Once you can access the instance (via serial console or fixed SSH), let’s diagnose the site issue:

• Check if Your Web Service is Listening on the Right Interface
  Look at your netstat -a output. Your web service (Nginx, Apache, or your app server) needs to listen on 0.0.0.0:PORT (all network interfaces) or your VM’s external IP—not just 127.0.0.1:PORT (only local access). If it’s only listening locally, external connections will get "connection refused".

  • For example, if you’re using Nginx, check its config file (usually /etc/nginx/sites-available/default) to make sure the listen directive isn’t restricted to localhost.

• Confirm the Web Service is Running
  Run commands like sudo systemctl status nginx (replace with your service name) to check if it’s active and running. If it’s stopped or failed, use sudo journalctl -u nginx to pull the service logs and see why it won’t start.

• Double-Check Firewall Rules (Even If You Think They’re Correct)
  Small oversights happen easily:

  • Make sure your firewall rule allows incoming traffic on your web port (80 for HTTP, 443 for HTTPS)
  • Verify the rule is applied to the correct target tags, and your problematic instance has those tags assigned
  • Check that no higher-priority "deny" rule is blocking the traffic (deny rules always take precedence over allow rules)

Bonus: Compare Configs with Your Working New Instance #

Since your new instance works perfectly, use it as a reference:

• Detach the disk from your problematic instance, attach it to the new instance as a secondary disk
• Mount the secondary disk and compare config files (like /etc/ssh/sshd_config, web server settings, or network configs) between the two instances to spot any differences that might be causing issues

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