解决Navicat连接PostgreSQL时authentication method 10报错的实用指南

1. 问题初探：当Navicat遇上PostgreSQL的“拦路虎”

如果你正在用Windows电脑，兴致勃勃地装好了PostgreSQL数据库，准备用Navicat这个图形化神器来连接管理，结果一点“连接”，弹出来的不是期待中的数据库列表，而是一个冷冰冰的错误提示——“authentication method 10 not supported”。相信我，那一刻的挫败感，我懂。这感觉就像你拿着最新款的智能门卡去开一扇老式机械锁，系统直接告诉你“协议不兼容，门打不开”。

这个报错，说白了就是Navicat和PostgreSQL在“握手”验证身份时，用的“暗号”对不上。PostgreSQL这边说：“我要求用SCRAM-SHA-256（这就是所谓的method 10）这种更安全的加密方式来验证密码。”但你的Navicat客户端版本可能有点老，它只认识MD5或者更旧的验证方式，一听“SCRAM-SHA-256”就懵了，直接回复：“大哥，你这方法（10号）我不支持啊！”

别慌，这个问题在PostgreSQL 10版本之后变得非常常见，尤其是当你安装的是较新的PostgreSQL（比如14、15、16乃至最新的17版），而Navicat的版本又没有及时更新时。好消息是，解决它的思路非常清晰，而且通常不需要你动数据库里宝贵的数据。我们主要有两条路可以走：要么，让PostgreSQL“迁就”一下，改用旧的、Navicat认识的验证方法；要么，让你的Navicat“升级”一下，去支持新的验证方法。接下来，我就带你一步步把这两条路都走通，彻底搞定这个烦人的错误。

2. 方案一：修改PostgreSQL配置（最常用、最直接）

这是我最先推荐你尝试的方法，因为它直接在数据库服务器端操作，不涉及客户端工具的修改，相对安全，也更容易理解。核心思路就是找到PostgreSQL的“客户认证配置文件”，告诉它：“对于来自本机的连接，别用那个高级的SCRAM-SHA-256了，先用简单的‘trust’或者‘md5’方式吧。”

2.1 找到关键文件：pg_hba.conf

这个文件是PostgreSQL的“门卫登记册”，全名叫“Host-Based Authentication”，它规定了哪些主机、哪些用户、通过哪种方式可以连接数据库。我们需要修改的就是它。

在Windows上，这个文件通常藏在你的PostgreSQL安装目录下的data文件夹里。一个典型的路径长这样：C:\Program Files\PostgreSQL\17\data\pg_hba.conf

请注意，这里的17是你的PostgreSQL主版本号，如果你安装的是15版，那路径就是...\PostgreSQL\15\data\。找到这个文件后，我强烈建议你先把它复制一份，备份到桌面或其他地方，万一改错了，我们还能有个后悔药。

2.2 编辑配置，调整验证方法

用记事本（Notepad）或者任何你喜欢的纯文本编辑器（比如Notepad++、VS Code）打开这个pg_hba.conf文件。你会看到里面有很多行配置，格式类似这样：

# TYPE DATABASE USER ADDRESS METHOD host all all 127.0.0.1/32 scram-sha-256 host all all ::1/128 scram-sha-256 local all all scram-sha-256

你需要关注的正是最后面那个METHOD字段。scram-sha-256就是导致报错的“method 10”。我们的目标是把针对本地连接（127.0.0.1、::1和socket连接）的验证方法改掉。

一个简单粗暴但有效的办法是改为trust。trust意味着完全信任来自这些地址的连接，不需要密码。这显然只适用于你个人电脑上的本地开发环境，绝对不要用于任何公开的网络服务器！

找到对应行，修改后像这样：

# IPv4 local connections: host all all 127.0.0.1/32 trust # IPv6 local connections: host all all ::1/128 trust # Unix-domain socket connections: local all all trust

如果你觉得trust太不安全（虽然本地开发问题不大），可以改为md5，即密码MD5加密验证。这样Navicat的老版本通常也能识别：

host all all 127.0.0.1/32 md5

2.3 重启服务，让配置生效

配置文件保存后，PostgreSQL服务并不会自动重新加载它。你需要重启PostgreSQL服务。

在Windows上操作非常方便：

1. 按下Win + R键，输入services.msc，回车打开“服务”管理器。
2. 在服务列表里，找到名字里包含“PostgreSQL”的服务。通常它的显示名类似“PostgreSQL Server 17”。
3. 右键点击这个服务，选择“重新启动”。

等待服务重启完毕。现在，再次打开Navicat尝试连接，大概率那个“authentication method 10”的错误已经消失了，你可以顺利连上数据库了。

3. 方案二：升级或修改Navicat客户端

如果修改数据库配置让你觉得心里不踏实，或者你的环境不允许改动服务器配置（比如连接的是远程测试服务器），那么我们可以从客户端入手。思路是：让Navicat支持SCRAM-SHA-256验证。

3.1 最佳选择：升级Navicat版本

这是最推荐、最一劳永逸的方法。Navicat在其较新的版本中（通常从Navicat 12版本后期开始，尤其是Navicat 15、16版本以后）已经原生支持了PostgreSQL的SCRAM-SHA-256验证。

你可以去Navicat官网查看你的版本是否过旧。如果正在使用较老的版本（比如Navicat 11或更早），强烈建议升级到最新版本。这不仅解决了验证问题，还能获得更好的功能支持和安全性更新。虽然这涉及商业授权，但对于正式开发环境来说，这是值得的投资。

3.2 硬核方案：手动修改Navicat的DLL文件（针对特定老版本）

这是一个非常经典的“民间偏方”，主要针对Navicat 12等一些特定老版本。其原理是，Navicat在连接时，会向PostgreSQL查询一个叫datlastsysoid的系统字段（在较老的PostgreSQL中存在），但新版的PostgreSQL已经移除了这个字段，导致查询失败，引发第二个错误：“错误:字段\”datlastsysoid\”不存在”。

解决方法是，找到Navicat安装目录下的一个关键动态链接库文件libcc.dll，用十六进制编辑器将其内部引用的datlastsysoid字符串修改为dattablespace（这是一个在新旧版本中都存在的字段）。

操作步骤（请务必谨慎，并提前备份！）：

1. 定位并备份文件：找到你的Navicat安装目录，例如C:\Program Files\PremiumSoft\Navicat Premium 12\。在这个目录下，找到libcc.dll文件。首先，复制这个文件，在相同目录下粘贴一份，命名为libcc.dll.backup，这是你的救命备份。

2. 使用十六进制编辑器：你需要一个能直接编辑二进制文件的工具。网上有很多在线的十六进制编辑器，例如hexed.it（一个纯前端的在线工具，文件不会上传到服务器，相对安全）。用浏览器打开这个网站。

3. 载入并搜索：在hexed.it网站中，点击“Open File”按钮，选择你刚才备份好的那个libcc.dll文件（注意不要选错成备份文件）。文件加载后，使用其搜索功能（通常是Ctrl+F），搜索字符串SELECT DISTINCT datlastsysoid。注意，要搜索完整的这个SQL语句片段。

4. 精确修改：找到这个字符串后，你会看到对应的十六进制值。你需要将datlastsysoid对应的十六进制部分，修改为dattablespace。幸运的是，这两个单词的字母数量相同，所以替换起来是“一对一”的，不会破坏文件结构。

   • datlastsysoid的十六进制表示大致是：64 61 74 6C 61 73 74 73 79 73 6F 69 64(d a t l a s t s y s o i d)
   • 你需要将其中的6C 61 73 74 73 79 73 6F 69 64(lastsysoid) 修改为74 61 62 6C 65 73 70 61 63 65(tablespace)
   • 最终，datlastsysoid就变成了dattablespace。在编辑时务必只修改这一处，并且确认光标位置和修改内容完全正确。

5. 保存并替换：修改完成后，在hexed.it中保存文件，通常会下载一个修改后的新文件。用这个新文件，替换掉Navicat安装目录下原来的libcc.dll文件（记得原文件你已经备份过了）。

6. 重启Navicat：关闭所有Navicat窗口，重新启动Navicat，再次尝试连接。

重要警告：此方法因Navicat和PostgreSQL的具体版本组合不同而效果各异，并非百分百通用。修改系统文件有风险，可能导致Navicat无法启动。它更像是一种在特定历史版本下的破解技巧。在动手前，请再次确认你是否已经尝试过方案一（改配置）和升级客户端，这两个是更规范、更安全的解决方案。

4. 深入理解：为什么会有这个错误？

知其然，更要知其所以然。我们花点时间聊聊背后的原理，这样以后遇到类似问题你就能自己分析了。

PostgreSQL的验证方式（pg_hba.conf里的METHOD）一直在演进，核心是为了更安全：

• trust：最早期的模式，完全信任，无需密码。仅用于绝对可信的内部环境（如本机）。
• password：发送明文密码，极不安全，现在基本不用。
• md5：发送MD5加密的密码。比明文好，但随着计算能力提升，MD5已被认为不够安全，存在被破解的风险。
• scram-sha-256(即 authentication method 10)：这是目前推荐的标准。它采用一种名为“SCRAM”的挑战-响应机制，并结合SHA-256哈希算法，整个过程密码本身不会在网络中传输，能有效防止重放攻击和密码嗅探，安全性远高于MD5。

PostgreSQL从版本10开始，默认的认证方法逐渐转向scram-sha-256。而许多旧的数据库客户端工具（包括某个时间段内的Navicat老版本）在设计时还未支持这一新协议，因此在握手阶段就会报错。

所以，这个错误的本质是“客户端与服务器之间的安全协议版本不匹配”。我们的解决方案，要么是让服务器降级协议以兼容老客户端（修改pg_hba.conf），要么是让客户端升级以支持新协议（升级Navicat或打补丁）。

5. 安全实践与进阶建议

解决了连接问题，我们还得回头看看安全。把验证方法改成trust毕竟是一种妥协，特别是在你可能需要远程连接或者对安全有一定要求的环境下。这里有一些更稳妥的长期建议：

1. 为本地开发环境使用md5而非trust即使是在本地，也建议你将pg_hba.conf中的METHOD从trust改回md5。这样，Navicat连接时至少需要输入一次密码。你可以在Navicat中保存这个密码，体验上几乎无差别，但多了一层基本的安全屏障。确保你的PostgreSQL数据库用户有一个强度足够的密码。

2. 创建专门的数据库用户不要一直使用超级用户（如postgres）进行日常开发和连接。为你的每个项目或应用创建一个专属的数据库用户，并授予最小必要的权限。在Navicat里，用这个专属用户进行连接和操作，这样即使密码泄露，影响范围也有限。

3. 关注版本兼容性矩阵这是一个很好的习惯。当你计划升级PostgreSQL服务器版本，或者更换、升级数据库管理工具时，先去官网查看一下兼容性说明。例如，在Navicat的官网或发布说明里，通常会明确写明从哪个版本开始支持PostgreSQL的SCRAM-SHA-256认证。提前了解可以避免很多不必要的麻烦。

4. 考虑使用其他免费且活跃的客户端工具如果你暂时不想为Navicat付费升级，市面上也有其他优秀的、免费开源的PostgreSQL图形化管理工具，它们通常跟随着PostgreSQL社区的步伐更新很快。例如pgAdmin（PostgreSQL官方维护）、DBeaver（功能强大的通用数据库工具）等。这些工具对新版PostgreSQL特性的支持通常非常及时，完全可以作为替代方案。

我自己在多年的开发和运维中，这三种方法（改配置、升客户端、换工具）都根据实际情况用过。对于个人学习或内部开发，改一下pg_hba.conf是最快的；对于团队协作和正式环境，统一升级到支持新协议的客户端是必须的；而探索像DBeaver这样的开源工具，往往能带来意想不到的效率和功能提升。希望这份详细的指南不仅能帮你解决眼前的问题，更能让你对数据库连接和安全有更深一点的理解。