在日常网络运维中，用户在尝试通过PPTP或L2TP协议连接远程VPN时，经常会遇到“错误691”——“远程服务器无法响应请求”或“用户名/密码无效”，这个错误看似简单，实则可能涉及多个层面的问题，包括账号配置、认证服务、网络策略和客户端设置，作为一名经验丰富的网络工程师，我将从问题定位到解决方案,系统性地帮助你快速排查并修复该错误。

需要明确的是，错误691通常发生在PPP（点对点协议）连接阶段，即客户端向VPN服务器发起身份验证时失败，最常见的原因是用户名或密码不正确，但这只是表象，真正根源往往隐藏在网络链路、服务器端配置或本地安全策略中。

第一步是确认基础信息，检查用户输入的用户名和密码是否准确无误，尤其注意大小写、特殊字符以及是否有空格，很多用户在输入密码时未开启大写锁定键，导致密码错误，某些企业使用RADIUS服务器进行集中认证，若RADIUS服务器宕机、配置错误或与VPN服务器通信异常，也会触发691错误，此时应登录RADIUS服务器查看日志,确认是否有来自该用户的认证失败记录。

第二步是检查账户状态，许多企业采用Active Directory或自建用户管理系统，如果用户账户被禁用、过期、或所属组权限不足，即使密码正确也无法通过认证，建议联系IT管理员确认该用户账户状态，并确保其具有访问VPN资源的权限，在Windows Server的RRAS（路由和远程访问服务）中，需检查“远程访问策略”中是否允许该用户登录。

第三步深入网络层排查，若认证服务正常，但依然报错691，则可能是网络路径问题，比如防火墙阻止了PPTP的TCP 1723端口或GRE协议（通用路由封装），导致客户端无法建立隧道，建议使用telnet测试服务器1723端口连通性，如不通则检查防火墙规则，确认ISP是否限制了PPTP流量（部分宽带运营商会屏蔽此类协议）,此时可考虑改用更安全的OpenVPN或IPSec协议替代PPTP。

第四步是客户端配置问题，部分用户在Windows系统中手动配置VPN时，未勾选“加密数据包”选项，或选择错误的认证类型（如CHAP vs MS-CHAP v2），建议删除旧配置，重新添加并选择“自动加密”或“要求加密”,同时确保操作系统已更新至最新补丁版本。

若上述步骤均无效，可启用详细日志追踪，在Windows客户端启用“调试模式”（注册表修改或组策略），或在Linux系统中使用tcpdump抓包分析，可精准定位失败环节，若日志显示“Access denied by server”，说明认证服务器拒绝；若显示“Connection timeout”,则为网络中断。

错误691并非单一故障，而是认证链路上的多点失效表现，作为网络工程师，我们应具备系统思维，逐层排查：从用户输入→认证服务→网络路径→客户端配置，最终找到根本原因，通过本文所述方法，可大幅提升排障效率,保障企业远程办公的安全与稳定。