PHP Guzzle 6出现cURL error 7连接拒绝问题求助

Hey Tom, let's break down this problem since you've already crossed off the basic checks (hosts file setup, working browser/terminal curl access). The issue is almost certainly tied to how your Dockerized php-fpm container handles network resolution or request execution—here are targeted steps to diagnose and fix it:

1. Validate Docker Network & Container Host Resolution #

First, let's confirm your php-fpm container can actually reach app-one/app-two internally:

• Exec into your php-fpm container with docker exec -it <your-php-fpm-container-id> sh
• Run ping app-one and curl http://app-one directly in the container. If these fail:
  • You might not have added the custom hosts correctly to the container. Docker often overrides /etc/hosts on restart, so instead of manually editing it, use the --add-host flag in your docker run command or extra_hosts in docker-compose:

    # Example docker-compose.yml snippet
    services:
      php-fpm:
        image: your-php-fpm-image
        extra_hosts:
          - "app-one:192.168.x.x"
          - "app-two:192.168.y.y"
    

  • If your apps are also running in Docker, ensure php-fpm is on the same custom Docker network as app-one/app-two—container-to-container communication relies on shared networks for service name resolution.

2. Audit Your Guzzle Request Configuration #

Double-check that your Guzzle setup isn't missing critical details that work in terminal curl but fail in PHP:

• Port Specification: If app-one runs on a non-default port (not 80/443), make sure your Guzzle base URI includes it (e.g., http://app-one:8080/ instead of just http://app-one/).
• SSL Verification: If you're using HTTPS with self-signed certificates, Guzzle will reject the connection by default. For testing, you can disable verification (never do this in production):

  $client = new GuzzleHttp\Client([
      'base_uri' => 'https://app-one/',
      'verify' => false, // Temporary test only
  ]);
  

  For production, point verify to your CA certificate file path.
• Proxy Settings: Ensure Guzzle isn't using an unintended proxy. Check if your container has HTTP_PROXY/HTTPS_PROXY environment variables set—these can redirect requests incorrectly.

3. Enable Guzzle Debug Mode for Detailed Insights #

Turn on Guzzle's verbose debug output to see exactly where the request fails. Add the debug option to your request:

use GuzzleHttp\Client;
use GuzzleHttp\Exception\RequestException;

$client = new Client();
try {
    $response = $client->request('GET', 'http://app-one/', [
        'debug' => fopen('php://stdout', 'w'), // Prints debug to container logs
    ]);
} catch (RequestException $e) {
    error_log('Guzzle Error: ' . $e->getMessage());
    if ($e->hasResponse()) {
        error_log('Response Body: ' . $e->getResponse()->getBody()->getContents());
    }
}

Check your container logs (docker logs <your-php-fpm-container-id>) for details like DNS resolution failures, connection timeouts, or invalid SSL handshakes—this will pinpoint the exact issue.

4. Check for Security Policy Restrictions #

If your host machine uses SELinux or AppArmor, these tools might block outgoing network requests from your php-fpm container:

• For SELinux, temporarily set it to permissive mode with sudo setenforce 0 and test again. If this fixes the issue, you'll need to add a policy to allow container network access.
• For AppArmor, check if your container is using a restrictive profile and adjust it as needed.

Final Notes #

Since browser and terminal curl work, the problem isn't with the target apps themselves—it's definitely a container-specific network or configuration quirk. Start with the container internal curl/ping test, then move to Guzzle debug output, and you'll find the root cause quickly.

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