Laravel 5.2邮件队列发件时出现fwrite() SSL断管错误

Hey there! Let’s figure out why your queue-based emails are failing while direct send() works perfectly. I’ve tackled similar issues before, so here’s a step-by-step breakdown of what to check:

1. Confirm Your Queue Worker Setup #

Laravel’s queue system relies on a running worker to process jobs—unlike send() which runs synchronously. Here’s what to verify:

• Make sure the queue worker is actually running. Use this command to start it (for production, pair it with a process manager like Supervisor to keep it alive):

  php artisan queue:work
  

• Double-check your .env file’s QUEUE_DRIVER is set to database (since you’re seeing jobs in the jobs and failed_jobs tables). Also, ensure your database connection is stable and the tables have the correct structure (you can re-run migrations for safety: php artisan migrate).

2. Get the Full Exception Message #

The truncated ErrorExcep... in the failed_jobs table isn’t enough to diagnose the issue. To see the full error:

• Run php artisan queue:failed to list all failed jobs and note the job ID.
• Use php artisan queue:retry {job-id} to re-run the failed job while watching your Laravel logs (storage/logs/laravel.log)—this will show the complete error trace.
• Alternatively, directly query the exception column in the failed_jobs table (it’s a long text field, so using a database client to view it will give you the full details).

Common full errors to look for:

• Missing email views (e.g., your CustomMail class references a view that doesn’t exist)
• Invalid data in $mailArr (like missing keys the mailable expects)
• Outdated mail configuration (the queue worker caches configs—restart it with php artisan queue:restart if you’ve changed .env mail settings)

3. Validate Your CustomMail Mailable Class #

Since send() works, the issue might be in how your mailable interacts with the queue. Let’s check the class structure:

• Ensure your CustomMail correctly accepts and uses the $mailArr data. A proper Laravel 5.2 mailable should look something like this:

  namespace App\Mail; // Adjust namespace if needed
  
  use Illuminate\Mail\Mailable;
  
  class CustomMail extends Mailable
  {
      public $mailArr;
  
      public function __construct($mailArr)
      {
          // Make sure all required keys exist in $mailArr
          $this->mailArr = $mailArr;
      }
  
      public function build()
      {
          return $this->subject($this->mailArr['subject'])
                      ->view('emails.custom') // Confirm this view exists at resources/views/emails/custom.blade.php
                      ->with(['description' => $this->mailArr['description']]);
      }
  }
  

• Check for typos in view paths or variable names—small mistakes that might go unnoticed in synchronous send() but break queue processing.

4. Check Worker Permissions & Environment #

Queue workers run as a specific user, which might differ from your web server user. This can cause issues like:

• Permission denied when trying to read email view files or write logs. Ensure the worker user has access to your Laravel project’s files.
• Memory limits: Laravel 5.2 workers might hit memory limits on longer tasks. Try starting the worker with increased memory:

  php artisan queue:work --memory=256
  

5. Test the Queue System Independently #

To rule out email-specific issues, create a simple test job to verify your queue works:

namespace App\Jobs;

use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;

class TestQueueJob implements ShouldQueue
{
    use InteractsWithQueue, SerializesModels;

    public function handle()
    {
        \Log::info('Test queue job executed successfully!');
    }
}

Dispatch it with:

dispatch(new \App\Jobs\TestQueueJob());

If this job runs successfully (check your logs), the queue system is working, and the problem is definitely in your email/mailable code. If it fails, you’ll need to fix your queue configuration first.

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