WordPress/WooCommerce EC2电商站持续GET请求致CPU满载问题咨询

First off, this is absolutely not normal—that internal subnet IP (172.31.33.229) spamming your WooCommerce product filter endpoints and wp-cron is creating a resource bottleneck that's crashing your EC2 instance. Let's walk through how to diagnose and fix this step by step.

1. Identify the Source of the Requests #

Since 172.31.x.x is an AWS private subnet IP, it's coming from within your VPC. Here's how to track it down:

• Check your VPC resources: Log into the AWS Console, navigate to your VPC dashboard, and list all EC2 instances, Lambda functions, load balancers, or other services running in that subnet. Look for the instance with IP 172.31.33.229—it could be a rogue monitoring script, a misconfigured data sync tool, or even another instance in your setup.
• Inspect local connections: On your WordPress server, run these commands to see what process is initiating the requests:

  netstat -anp | grep 172.31.33.229
  # Or use ss for more detailed info
  ss -tp | grep 172.31.33.229
  

  This will show you the PID and process name associated with the connections, helping you pinpoint if it's a local script or an external internal service.

2. Fix the Root Causes #

a. Troubleshoot WooCommerce Filter Requests #

The repeated GET requests to product category filter URLs look like a loop from a misbehaving plugin or automation tool:

• Disable filter plugins temporarily: Deactivate any WooCommerce product filter plugins you're using (like WooCommerce Product Filters, YITH WooCommerce Ajax Product Filter, etc.). Wait the 12-hour window to see if the CPU spike stops. If it does, update the plugin to the latest version or replace it with a more stable alternative.
• Check for custom scripts: If you have any custom code or automation tools (like scrapers, inventory sync scripts) that interact with product filters, audit them for infinite loops or excessive request logic.

b. Fix wp-cron Configuration #

The frequent wp-cron POST requests might be compounding the issue. Bitnami's WordPress often relies on web-triggered wp-cron, which can spiral if requests are being forced repeatedly:

• Switch to system cron: Disable web-triggered wp-cron first by adding this line to your wp-config.php (located at /opt/bitnami/apps/wordpress/htdocs/wp-config.php):

  define('DISABLE_WP_CRON', true);
  

• Set up a system cron job: Run crontab -e as the bitnami user, then add this line to trigger wp-cron every 5 minutes (adjust frequency as needed):

  */5 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/wordpress/htdocs/wp-cron.php > /dev/null 2>&1
  

• List cron events: Use WP CLI to check for abnormally frequent cron jobs:

  /opt/bitnami/wp-cli/bin/wp cron event list
  

  If you see any events running every few seconds, delete or reschedule them with wp cron event delete <event-hook>.

3. Immediate Mitigation to Prevent Crashes #

Before you fully diagnose the root cause, stop the IP from overwhelming your server:

• Block the IP in Apache: Edit your site's Apache configuration (or .htaccess file in your WordPress root) to add:

  <RequireAll>
      Require not ip 172.31.33.229
  </RequireAll>
  

  Then restart Apache:

  sudo /opt/bitnami/ctlscript.sh restart apache
  

• Optimize php-fpm: Bitnami's default php-fpm settings might allow too many processes, exacerbating CPU load. Edit /opt/bitnami/php/etc/php-fpm.d/www.conf and adjust these values based on your EC2 instance's CPU cores (e.g., for a 1-core instance):

  pm.max_children = 6
  pm.start_servers = 2
  pm.min_spare_servers = 1
  pm.max_spare_servers = 3
  

  Restart php-fpm to apply changes:

  sudo /opt/bitnami/ctlscript.sh restart php-fpm
  

4. Deep Dive for Persistent Issues #

If the problem returns after blocking the IP or disabling plugins, enable debugging to catch hidden errors:

• Enable WordPress debug logging: Add these lines to wp-config.php:

  define('WP_DEBUG', true);
  define('WP_DEBUG_LOG', true);
  define('WP_DEBUG_DISPLAY', false);
  

  Check the wp-content/debug.log file for errors related to filter plugins, cron jobs, or custom code.
• Analyze access logs: Look at the full access log (/opt/bitnami/apache2/logs/access_log) for the User-Agent string associated with the 172.31.33.229 requests. This can tell you if it's a browser, a script, or a specific service making the calls.

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