我之前维护Airflow 1.x集群的时候也碰到过几乎一模一样的情况——调度器显示任务入队，但RabbitMQ队列空、Worker完全没动静，结合你的部署环境和已经完成的排查，给你几个针对性的排查点：

1. 强制统一所有节点的Airflow配置 #

Airflow 1.x对配置一致性要求极高，尤其是Celery相关参数，必须确保Webserver、Scheduler、所有Worker节点的airflow.cfg里以下参数完全一致：

• executor = CeleryExecutor（别不小心写成了SequentialExecutor或者LocalExecutor）
• broker_url = amqp://<你的RabbitMQ用户名>:<密码>@主机1:5672/<你的vhost>（注意如果用了自定义vhost，必须明确写在URL里，而且要确认该用户对这个vhost有读写权限）
• celery_result_backend = db+postgresql://<Postgres用户名>:<密码>@主机1:5432/airflow
• celery_queues = default（如果没自定义队列，Worker默认监听default，DAG里也别指定其他队列）

可以在每个节点执行这条命令快速验证：

airflow config get-value celery broker_url && airflow config get-value celery celery_result_backend

2. 深挖RabbitMQ的队列与日志细节 #

登录主机1的RabbitMQ管理后台（默认端口15672），重点看：

• 对应vhost下有没有airflow队列（或你自定义的队列名），队列的Ready/Unacked计数是不是始终为0？如果调度器说任务入队但这里没数据，大概率是调度器没真正把任务发出去
• 翻RabbitMQ的日志（/var/log/rabbitmq/rabbit@<主机名>.log），有没有权限拒绝、连接中断的报错，比如“access to vhost '<你的vhost>' refused for user '<你的用户>'”

另外在Worker节点执行这条Celery命令，确认Worker确实在监听正确的队列：

celery inspect active_queues

3. 扒Scheduler日志的关键细节 #

虽然你已经开了DEBUG级日志，但可以重点过滤任务入队相关的日志：

grep -E "queued|Sent task" /path/to/airflow/scheduler/logs/scheduler.log

• 如果看不到Sent task <任务ID> to queue <队列名>的日志，说明调度器根本没完成入队动作，可能是任务实例状态更新失败
• 如果看到类似“Failed to send task to broker”的报错，直接定位到Broker通信问题

4. 验证Worker的Celery环境兼容性 #

Airflow 1.9.0对依赖版本卡得很严，你用的Celery 4.1.1和RabbitMQ 3.7.5理论上兼容，但要确保所有节点的PyPy环境依赖完全一致：

• 在Worker节点执行airflow celery worker --check，看有没有兼容性报错
• 用pip freeze | grep kombu检查所有节点的kombu版本（Airflow 1.9.0要求kombu<4.0，版本不一致会导致Broker通信异常）

5. 直接查Postgres里的任务实例状态 #

登录Airflow的Postgres数据库，执行这条SQL看看任务实例的真实状态：

SELECT task_id, state, queued_dttm, execution_date 
FROM task_instance 
WHERE dag_id = '<你的DAG ID>' 
ORDER BY execution_date DESC LIMIT 10;

• 如果state是queued但queued_dttm为空，说明调度器只是把任务标记成了queued，但没真正发去Broker
• 如果queued_dttm有值但RabbitMQ队列没数据，那肯定是Broker这边的问题

最后补充个小技巧：如果以上排查都没问题，试试按顺序重启所有组件——先停所有Worker，再停Scheduler和Webserver，接着重启RabbitMQ和Postgres，最后依次启动Webserver、Scheduler、Worker。Airflow 1.x对启动顺序挺敏感的，有时候只是组件启动时机不对导致的通信阻塞。

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