虚拟机svn checkout失败通常由虚拟机网络模式配置错误或防火墙拦截3690端口导致，优先排查网络链路，再验证账号权限和SSL证书。 下面按排查优先级逐个拆解,每一步都能直接上手操作。
虚拟机svn checkout失败先排查网络链路
宿主机能正常checkout吗
先做一个对照实验，在宿主机上执行svn checkout命令，看能否正常拉取代码。宿主机可以而虚拟机不行，问题基本锁定在网络层。
- 宿主机同样失败：SVN服务端异常，或本地hosts解析有问题
- 宿主机成功、虚拟机失败：网络模式、防火墙或DNS配置有差异
这个对照实验能直接砍掉一半排查范围,省下大量时间。
确认虚拟机网络模式
VMware和VirtualBox的虚拟网卡默认不通外部网络的情况比较常见,检查虚拟机的网络适配器设置：
- NAT模式：虚拟机共享宿主机IP访问外部网络，但部分公司内网的SVN服务器会拒绝NAT来源的连接请求
- 桥接模式：虚拟机直接获取物理局域网的IP，适合访问内网SVN，但需要确保IP没有冲突
- 仅主机模式：只能和宿主机通信，访问不了其他设备
如果你的SVN服务器在公司内网，而虚拟机用的是NAT模式，连接被服务端拒掉的可能性就比较大，改成桥接模式后重启虚拟机网络,再试一次checkout。
ping不通服务器时的处理思路
虚拟机里执行ping svn服务器IP,如果返回超时：
- 检查虚拟网卡是否启用了DHCP自动获取IP
- VMware里编辑虚拟机设置，确认网络连接勾选了”已连接”和”启动时连接”
- 用
ipconfig（Windows）或ip addr（Linux）确认虚拟机拿到了合法IP
能ping通但checkout还是失败，说明网络链路是通的,问题出在端口或应用层。
svn checkout 认证失败与权限配置问题
账号密码正确却报认证失败
这种情况在虚拟机上相当常见，尤其是已保存的凭证过期后,SVN客户端会直接用本地缓存的旧密码去请求服务器。
- 进入SVN客户端设置，找到”已保存数据”或”认证数据”
- 清除保存的认证信息
- 重新checkout，输入正确的账号密码
TortoiseSVN的清除路径是：右键菜单 → Settings → Saved Data → 点击Authentication数据的Clear按钮，命令行客户端用svn auth --remove清除指定主机名的认证缓存。
检查SVN账号在服务端的权限
服务端配置了目录级别权限控制的话，虚拟机的访问IP如果不在授权范围内，即使密码正确也会被拒，确认服务端authz文件中[/]或对应路径的权限条目是否包含当前虚拟机的IP段。
使用svn://协议时，部分服务端配置要求客户端IP必须与账号绑定的IP一致，桥接模式下虚拟机IP变化会导致偶发认证失败，业内专家指出，这类问题最难定位的原因在于报错信息不明确，服务端日志里通常记录的是”拒绝访问”而不是具体原因,排查时需要留意服务端日志中客户端的源IP和认证时间点。
vmware虚拟机svn连接超时怎么办
防火墙对3690端口的影响
SVN默认走3690端口，VMware虚拟机的防火墙策略通常与宿主机独立,需要单独放行。
Windows虚拟机执行以下命令放行：
netsh advfirewall firewall add rule name="SVN" dir=in action=allow protocol=TCP localport=3690
Linux虚拟机用：
firewall-cmd --permanent --add-port=3690/tcp && firewall-cmd --reload- 或
iptables -A INPUT -p tcp --dport 3690 -j ACCEPT
放行后重新checkout,超时报错通常会消失。
虚拟机时间不同步导致的handshake失败
SVN的认证握手依赖客户端和服务端的时间戳校验，虚拟机长时间挂起后恢复，系统时间可能偏离真实时间,多数情况下会导致SSL握手失败或认证失败。
在虚拟机里执行时间同步：
- Windows：
w32tm /resync - Linux：
ntpdate pool.ntp.org或timedatectl set-ntp true
同步完成后，在虚拟机设置里开启”与主机时间同步”选项,可以避免后续再次出现同类问题。
Linux虚拟机svn客户端配置的三个关键点
命令行svn客户端的常见坑
Linux虚拟机里用svn checkout报RA layer request failed时，通常是客户端缺少依赖库，确认已安装subversion完整包：
- Ubuntu/Debian：
apt install subversion libsvn-perl - CentOS/RHEL：
yum install subversion mod_dav_svn
配置文件优先级问题
Linux下SVN客户端依次读取系统级、用户级和项目级的配置文件，仓库根目录下的.svn目录内配置优先级最高，如果项目组维护了servers或config文件，其中的代理设置可能覆盖全局配置,导致虚拟机的代理环境变量冲突。
检查~/.subversion/servers中的http-proxy-host，如果虚拟机所在网络不需要代理，注释掉这几行,然后重新执行checkout。
SVN checkout失败错误信息速查表
| 错误信息 | 常见原因 | 处理方式 |
|---|---|---|
Could not resolve hostname |
DNS解析失败 | 检查虚拟机DNS，改用IP直连测试 |
Connection refused |
端口未开放或服务未启动 | 确认服务端svnserve运行状态 |
Authentication failed |
密码错误或权限不足 | 清除认证缓存，核对authz配置 |
Server sent unexpected return value |
路径不存在或访问被拒绝 | 检查URL是否写错，确认目录存在 |
SSL handshake failed |
证书过期或时间不同步 | 更新CA证书，同步虚拟机时间 |
E170013: Unable to connect |
网络链路中断 | 按上文顺序排查网络模式与防火墙 |
把以上步骤按顺序走一遍，多数虚拟机svn checkout失败问题都能定位到具体环节。 网络模式错误和防火墙拦截是出现频率最高的两个根因，先处理这两个,成功率最高。
虚拟机SVN检出失败相关问题解答
虚拟机里svn checkout一直卡在connecting怎么办
先等待一两分钟，如果始终没有响应，在宿主机上测试telnet svn服务器IP 3690看端口通不通，端口通的话，检查虚拟机的MTU值是否过大，过大的MTU会导致大包被丢弃，表现为连接建立后卡住,降低虚拟网卡MTU到1400再试。
桥接模式下虚拟机svn checkout还是失败
桥接模式下，确认虚拟机的IP和宿主机在同一网段，并且网关指向物理路由器，部分公司网络启用了端口隔离，虚拟机即使拿到合法IP也无法访问其他设备,这种情况下需要联系网络管理员开放访问权限。
换用svn+ssh协议能绕过这些问题吗
svn+ssh走22端口，可以避开3690端口的防火墙限制，但需要服务端配置SSH公钥认证，如果服务端支持，在虚拟机上生成密钥对，将公钥添加到服务端账号的authorized_keys文件中，然后使用svn+ssh://协议连接即可。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/618673.html
