查看熵池大小应读 /proc/sys/kernel/random/poolsize（默认4096 bit），而实时可用熵值必须读 /proc/sys/kernel/random/entropy_avail，低于100将导致 /dev/random 阻塞，需用 watch -n 1 cat /proc/sys/kernel/random/entropy_avail 持续监控。
熵池大小直接决定 /dev/random 是否阻塞，而查看它最准的方式就是读 /proc/sys/kernel/random/poolsize ——这不是估算值，是内核硬编码的池容量上限（单位：bit），现代 Linux 默认是 4096。
怎么查当前可用熵值（entropy_avail）
这是你真正该盯住的数字，它反映此刻池里“还能用多少随机性”。低于 100 就大概率触发阻塞：
- 执行
cat /proc/sys/kernel/random/entropy_avail，返回整数如237或42 - 别只看一次：用
watch -n 1 cat /proc/sys/kernel/random/entropy_avail持续观察波动趋势 - 如果长期卡在 50–150 区间小幅震荡，说明熵入不敷出——尤其常见于无鼠标/键盘、低 I/O 的云主机或容器
- 某些旧版 Java（如 OpenJDK 8u232 前）默认用
/dev/random初始化SecureRandom，哪怕只读 1 字节也会卡住，现象是 Tomcat 启动慢、ssh-keygen挂起、openssl genrsa停住
/dev/random 和 /dev/urandom 的行为差异在哪
关键不是“谁更安全”，而是“谁会停”：
-
/dev/random是阻塞式：当entropy_avail （默认 64）时，<code>read()调用直接挂起，直到新熵注入 -
/dev/urandom是非阻塞式：内核 ≥ 3.17 后已不依赖实时熵值，用 ChaCha20 等算法持续输出；但系统刚启动时若熵为 0，它生成的初始随机数确实可预测 - 很多应用（如 OpenSSL 1.1.1+）默认仍走
/dev/random路径，哪怕只是取种子——所以补熵比换设备文件更治本
为什么 poolsize 是 4096 却还总不够用
池大小固定，但“填充速度”取决于硬件噪声源。虚拟机、容器、无外设服务器天然缺熵源：
- 物理机靠键盘、鼠标、磁盘中断等提供噪声；VPS 或 KVM 虚拟机基本没有这些，主要靠定时器抖动和中断延迟，速率极低
-
poolsize是上限，entropy_avail才是实时水位；就像油箱是 50L，但油表显示只剩 2L - 某些服务（如 GPG 密钥生成、TLS 握手）单次请求就需几百 bit 熵，池子再大也扛不住持续抽水
- 别信“增大
poolsize”的误导方案——内核不允许运行时修改该值，强行改需重新编译内核，且无实际意义
补熵该选 haveged 还是 rng-tools
优先用 haveged，尤其在没硬件 RNG 的环境：
-
haveged利用 CPU 时间戳抖动（TSC）生成熵，启动快、资源占用低、兼容所有 x86/ARM 虚拟机，Debian/Ubuntu 直接sudo apt install haveged && sudo systemctl enable --now haveged -
rng-tools依赖硬件 RNG（如 Intel RDRAND、AMD SVM），在纯软件虚拟化环境里必须 hack：改rngd启动参数为-r /dev/urandom，本质是绕过熵池，有安全争议 - 验证是否生效：补熵后
cat /proc/sys/kernel/random/entropy_avail应稳定在 2000+；再跑一次dd if=/dev/random of=/dev/null bs=1 count=1，不该卡住
熵问题最隐蔽的地方在于：它不报错，只“慢”。你看到的 SSL 握手超时、Java 启动卡顿、密钥生成停滞，背后可能只是 entropy_avail 长期低于 100——而这个数字，连监控告警都常被忽略。
