结合你遇到的情况，既然已经排除了驱动版本、密码正确性、网络连接（VPN/校园网）以及客户端工具（DataGrip/SQL Developer）的问题，我给你几个额外的排查方向试试：

1. 精确匹配用户名/密码的大小写与格式 #

Oracle 12c及之后版本默认开启密码大小写敏感，再加上学校可能有特殊的账号配置，试试这两种操作：

• 把密码用双引号括起来输入（比如你的密码是MyPass_2023，就输入"MyPass_2023"），强制Oracle按照你输入的精确字符匹配
• 如果你学校用的是统一身份认证，确认是否需要给用户名加域名前缀，比如SCHOOLDOMAIN\你的学号或者你的学号@school.edu，有些学校的Oracle会和AD域集成，必须带前缀才能登录

2. 核对连接配置的核心参数 #

仔细检查PDF里的配置项，别漏掉细节：

• 区分服务名和SID：Oracle连接时需要填写服务名（Service Name）或SID，很多人容易搞混。你可以在旧平台执行这条语句获取正确值：

  -- 获取服务名
  SELECT sys_context('userenv','service_name') FROM dual;
  -- 获取SID
  SELECT instance_name FROM v$instance;
  

  然后在DataGrip/SQL Developer里对应填写，别填反了
• 确认端口号：默认Oracle端口是1521，但有些学校会修改端口，务必和PDF里的一致，别填错
• 尝试TNS连接：如果学校提供了TNS配置文件（通常是tnsnames.ora），直接导入这个文件来建立连接，比手动填写Basic参数更不容易出错

3. 排查账号的远程连接权限 #

你能在旧平台登录，不代表账号有直接远程连接数据库的权限：

• 旧平台可能是通过应用中间件间接连接数据库，你的账号可能没有CREATE SESSION权限，需要学校IT给你开通远程连接权限
• 有些学校的数据库会限制登录IP段，即使你挂了VPN，VPN分配的IP可能不在允许范围内，试试切换VPN节点（如果有多个可选），或者确认VPN是否正确路由了数据库的流量

4. 测试网络端口的连通性 #

有时候VPN显示连接成功，但数据库端口实际是不通的，用命令行工具测试一下：

# Windows用telnet
telnet 学校数据库IP 端口号
# Linux/macOS用nc
nc -zv 学校数据库IP 端口号

如果显示连接超时或被拒绝，说明网络层面有拦截，这种情况还是得找学校IT，但至少能定位问题点

5. 匹配客户端与服务器的字符集 #

虽然这个导致ORA-01017的概率不高，但字符集不匹配可能导致密码传输时乱码。先在旧平台查服务器字符集：

SELECT value FROM nls_database_parameters WHERE parameter='NLS_CHARACTERSET';

然后在DataGrip/SQL Developer里把客户端字符集设置成和服务器一致（比如服务器是AL32UTF8，客户端也设成AL32UTF8）

如果以上都试过还是不行，建议找同专业里有没有成功连接的同学，对比你们的配置细节，或者再发邮件催学校IT的时候把你做过的所有排查步骤附上，方便他们快速定位问题。

备注：内容来源于stack exchange，提问作者Sotiris Kettenis