开启VPN时启动Phoenix项目无法连接Postgres报eaddrnotavail错误如何解决？

eaddrnotavail是操作系统网络栈层面的报错，本质是应用发起出站连接时，系统无法找到可用于绑定的源端口/源地址，或是目标地址在当前路由表中无可达路径。结合给出的场景特征，具体触发诱因可分为三类：

• VPN启动阶段的路由初始化时序冲突
  全隧道类VPN客户端启动时会优先抢占系统默认路由、替换出站流量的转发路径，整个路由表、网卡规则的全量加载过程通常需要1-3秒。如果VPN刚启动完成就立刻拉起Phoenix应用，Phoenix在启动阶段会一次性初始化全量Postgres连接池，此时如果路由表还未完成对目标PG地址网段的规则映射，就会因为找不到可用出口路径触发地址不可达错误。这也能解释为何启动完成后再开VPN可保持运行正常：已建立的TCP长连接不会被新增的路由规则打断，不需要重新做源地址绑定。
• 临时端口池被VPN虚拟网卡占用
  应用发起出站TCP连接时，需要从系统分配的临时端口池中选取一个空闲端口作为源绑定地址。部分VPN客户端在版本更新后，会把自身虚拟网卡的通信端口范围设置成和系统默认临时端口池重叠。Phoenix启动时需要同时向Postgres发起数十到上百个连接，每个连接都要占用一个临时端口，一旦端口被VPN的虚拟网卡通信占用，系统就会因为找不到可用的绑定端口抛出eaddrnotavail错误。这类配置变更恰好匹配“之前从未出现同类问题、今早开始才报错”的时间特征。
• DNS解析结果与VPN路由规则错位
  VPN刚启动时，系统本地的DNS缓存还未同步更新。Phoenix启动时如果通过主机名解析Postgres地址，拿到的是VPN生效前的旧IP段，而当前所有出站流量已经被强制切到VPN隧道，这个旧IP段不在VPN的可路由范围内，就会触发地址不可达报错。

• 先做问题定位校验：在VPN保持开启的状态下，手动用psql命令连接Phoenix配置中指定的Postgres地址，验证是否复现eaddrnotavail报错。如果手动连接就触发报错，说明问题不在Phoenix/Elixir应用层，根源在VPN的网络配置。
• 解决端口池冲突：对比系统默认出站临时端口范围、VPN虚拟网卡占用的端口范围，调整二者的区间避免重叠；也可以在Phoenix的Postgres连接配置中，为数据库连接单独指定本地绑定的端口区间，规避被VPN占用的端口段。
• 优化启动时序：不要将Phoenix应用设置为和VPN客户端同一启动序列的开机自启项，等VPN的路由规则、DNS缓存完全加载稳定后，再拉起应用。也可以在Phoenix的数据库连接配置中增加临时错误重试逻辑，碰到eaddrnotavail这类启动阶段的瞬时网络错误时，间隔2-3秒自动重试连接，待网络栈稳定后即可正常建立连接，不会直接启动失败。
• 解决DNS错位问题：在系统hosts文件中直接写入Postgres主机名与对应IP的映射关系，跳过VPN启动阶段的动态DNS解析流程，避免解析到不可达的旧IP地址。

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