直接读 /proc/sys/kernel/random/entropy_avail 是唯一可靠方式，返回值低于 100 就会触发 /dev/random 阻塞，导致 OpenSSL、Java、Nginx TLS 初始化等卡住；执行 cat /proc/sys/kernel/random/entropy_avail 即可获取实时数值，若长期低于 100 或卡在 50–150 区间，表明熵入不敷出，需用 haveged 等工具补熵。
直接读 /proc/sys/kernel/random/entropy_avail 是唯一可靠方式，返回值低于 100 就会触发 /dev/random 阻塞，导致 OpenSSL、Java、Nginx TLS 初始化等卡住——这不是配置问题，是系统真没随机性了。
怎么快速确认当前熵值是否过低
执行 cat /proc/sys/kernel/random/entropy_avail 即可获取实时数值：
- ≥ 1000：桌面或物理机常见，基本无风险
- 200–1000：VPS 或轻量云主机典型值，部分服务（如旧版 Java）可能短暂等待
- < 100：大概率已阻塞，
ssh-keygen、openssl genrsa、Tomcat 启动 HTTPS 端口都会卡在 openat(/dev/random)
别只看一次——用 watch -n 1 'cat /proc/sys/kernel/random/entropy_avail' 持续观察。如果数值长期卡在 50–150 区间小幅震荡，说明熵入不敷出，尤其常见于无键盘/鼠标、低 I/O 的容器或 KVM 虚拟机。
为什么 dd if=/dev/random 会卡住
这是验证熵枯竭最直接的方法：
-
timeout 3 dd if=/dev/random of=/dev/null bs=1 count=1 2>/dev/null || echo "blocked"—— 若超时输出blocked，基本锁定问题 -
/dev/random在entropy_avail低于read_wakeup_threshold（默认 64）时挂起，不靠超时根本看不出 -
/dev/urandom几乎瞬回，但很多应用（如 OpenJDK 8u232 前的SecureRandom）默认仍走/dev/random初始化路径
注意：strace -e trace=openat,read java -version 可看到卡在哪一行系统调用，比猜更准。
补熵该选 haveged 还是 rng-tools5
优先用 haveged，尤其在没硬件 RNG 的环境：
-
haveged利用 CPU 时间戳抖动（TSC）生成熵，启动快、资源占用低、兼容性好；安装后 2 秒内entropy_avail通常能拉到 3000+ -
rng-tools5依赖/dev/hwrng设备存在，KVM 虚拟机需宿主机透传virtio-rng并 guest 加载virtio_rng模块，否则systemctl start rng-tools5会静默失败 - 检查硬件 RNG 是否就位：
ls -l /dev/hwrng和lsmod | grep rng；若都为空，装rng-tools5也没用
Debian/Ubuntu：sudo apt install haveged && sudo systemctl enable --now haveged；RHEL/CentOS 8+：sudo dnf install haveged && sudo systemctl enable --now haveged。
临时绕过阻塞但不解决根源
某些场景下可快速缓解，但只是掩耳盗铃：
- Java 应用加 JVM 参数：
-Djava.security.egd=file:/dev/urandom，强制跳过/dev/random初始化 - 临时调高唤醒阈值：
sudo sysctl -w kernel.random.read_wakeup_threshold=128，降低阻塞频率，但设太高（如 >512）会让 OpenSSL 3.0+ 记录RAND_status=0警告 - 改
/dev/random为符号链接指向/dev/urandom？别试——现代内核（≥5.17）已禁止这种 hack，且破坏语义
真正有效的做法永远是补熵源：物理机启用 rdrand/rdrnd，KVM 虚拟机务必加载 virtio_rng，无硬件条件就用 haveged。熵池不是“调大就能行”的参数，而是必须由真实噪声持续注入的生命线。
