Docker Desktop WSL2环境下调用/dev/random性能缓慢，如何解决？

该问题本质是WSL2架构下系统熵池不足导致的阻塞问题：
WSL1为系统调用转译层，会直接复用Windows宿主的熵源，/dev/random调用不会出现阻塞；WSL2运行在轻量级虚拟化架构下，默认缺少硬件随机数生成器作为稳定熵源，当加密库频繁调用阻塞型的/dev/random时，熵池耗尽就会引发操作卡顿。

以下方案均不需要修改或替换加密库：

• 方案1：容器启动时挂载/dev/urandom替代/dev/random（最便捷，侵入性最低）
  启动容器时增加参数即可，无需修改其他配置：

  docker run --device /dev/urandom:/dev/random [你的其他启动参数] 镜像名
  

  若使用docker-compose，可在服务配置中增加devices配置项：

  services:
    你的服务名:
      image: 镜像名
      devices:
        - /dev/urandom:/dev/random
  

  注意：当前主流Linux发行版中/dev/urandom的加密安全性与/dev/random基本一致，仅极端高等级加密合规场景需要额外评估适用性。

• 方案2：在WSL2发行版中安装熵生成工具提升熵池生成速度（全局生效，无需修改容器配置）
  直接在你Docker Desktop所使用的WSL2发行版中执行以下操作即可：

  1. 安装rng-tools工具：

  # Debian/Ubuntu系发行版
  sudo apt update && sudo apt install -y rng-tools
  

  2. 修改配置文件/etc/default/rng-tools，添加如下内容：

  HRNGDEVICE=/dev/urandom
  

  3. 启动服务并设置开机自启：

  sudo systemctl start rng-tools
  sudo systemctl enable rng-tools
  

• 方案3：修改Java应用启动参数（仅适用于加密库调用JVM原生SecureRandom接口的场景）
  给Java应用启动命令添加如下参数，指定JVM使用非阻塞的随机数源：

  java -Djava.security.egd=file:/dev/./urandom -jar 你的应用包名.jar
  

• 方案4：TPM熵源直通（适用于有严格FIPS合规要求、不能使用/dev/urandom替代的场景）
  若你的Windows宿主搭载了TPM2.0模块，可配置WSL2内核直通TPM的硬件随机数源，从根源上获得符合合规要求的高熵值，操作相对复杂，可通过WSL2官方内核配置逻辑完成编译和配置。

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