Harbor报错:dial tcp 192.168.1.52:443: connect: connection refused

博主在部署Harbor后登录遇到问题,首次部署仅遇x509问题,添加证书认证可解决。再次部署解决x509问题后又遇新问题,经排查非网络问题,而是Harbor本身问题,除部署机器外同网段机器做证书认证可登录,最后重启Harbor成功登录。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

之前在部署完harbor之后登录过程中,只遇到了x509问题,这个问题很好解决,添加证书认证即可。

后来我再次部署harbor时,登录过程中,解决完x509问题后,又遇到了一个新问题。

[root@master2 ~]# docker login harbor.uqp.com
Username: admin
Password: 
Error response from daemon: Get https://harbor.uqp.com/v2/: dial tcp 192.168.1.52:443: connect: connection refused

在网上搜了半天,要么是去编辑/etc/docker/daemon.json文件,要么是在docker.service文件中添加--insecure-registry,反复尝试,没有作用,还是会报443: connect: connection refused的错误。

然后检查了IP及端口,可以ping通和telnet上,这说明也不是网络的问题,那就是harbor本身的问题了,但奇怪之处在于,除了部署harbor的机器登录不上之外,其它同网段的机器全部没有问题,只要做了证书认证就都可以登录成功。

于是重新启动harbor:

[root@master2 ~]# cd harbor/

[root@master2 harbor]# docker-compose down -v

[root@master2 harbor]# docker-compose up -d

[root@master2 harbor]# docker login harbor.uqp.com
Username: admin
Password: 
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

总算可以成功登录了,还真是操蛋的问题,有点奇葩。

harbor安装过程:https://blog.csdn.net/miss1181248983/article/details/87856200


### Harbor Docker Login Connection Refused 解决方案 当尝试通过 `docker login` 访问 Harbor 仓库时,可能会遇到 `connection refused` 错误。以下是可能的原因以及解决方案: #### 可能原因分析 1. **端口未开放或防火墙阻止** 如果目标服务器上的指定端口(如 80443)被防火墙阻塞或者未正确监听,则会出现连接拒绝的情况[^1]。 2. **Docker 客户端配置不完整** 默认情况下,Docker 不信任自签名证书或非 HTTPS 地址。因此,在访问私有镜像库(如 Harbor)时,需要显式配置 insecure-registries 参数来允许非加密通信[^3]。 3. **DNS 配置冲突** 当 Docker 使用特定 DNS 设置时,可能导致内部服务无法正常解析域名,从而引发连接问题。此情况通常发生在复杂网络环境中,需调整相关参数以支持正确的名称解析[^4]。 4. **Harbor 自身服务状态异常** 若 Harbor 的核心组件(例如 Core API、Redis 缓存等)未能正常运行,也可能导致外部客户端无法完成身份验证过程[^2]。 --- #### 具体解决方法 ##### 方法一:修改 Docker Daemon 配置文件 编辑 `/etc/docker/daemon.json` 文件,添加以下内容: ```json { "registry-mirrors": [], "insecure-registries": ["192.168.10.124:80"] } ``` 保存后重启 Docker 服务以应用更改: ```bash sudo systemctl daemon-reload && sudo systemctl restart docker ``` > 注:上述操作允许 Docker 对于 IP 地址为 `192.168.10.124` 并使用端口号 `80` 的注册表执行无 TLS 加密的操作。 ##### 方法二:更新 Systemd Service Unit File 对于某些 Linux 发行版,默认的 Docker 启动脚本路径位于 `/usr/lib/systemd/system/docker.service` 中。可以在此处追加额外选项启用对本地私有仓库的支持: ```ini [Service] ExecStart= ExecStart=/usr/bin/dockerd --add-runtime=nvidia-container-runtime=/usr/bin/nvidia-container-runtime -H fd:// --containerd=/run/containerd/containerd.sock --insecure-registry=192.168.10.124:80 ``` 同样地,记得刷新守护进程缓存并重新加载服务实例: ```bash sudo systemctl daemon-reload && sudo systemctl restart docker ``` ##### 方法三:确认 Harbor 实例可用性 确保 Harbor 所依赖的服务均处于健康状态,尤其是 HTTP(S) 接入层代理程序 Nginx 和数据库 MySQL 是否能够响应请求。可以通过查看日志文件定位潜在故障点;比如检查 /var/log/nginx/error.log 或者查阅 harbor-core 日志记录是否存在类似 “failed to start server” 提示信息。 另外需要注意的是,如果启用了 SSL/TLS 功能,请务必上传合法有效的 X.509 数字凭证至对应目录,并同步告知所有关联方导入根 CA 至受信存储区以便建立双向握手关系。 ##### 方法四:排查 DNS 解析障碍 假如发现即使解决了前面提到的安全性和权限方面的问题依旧存在连通性的困扰,那么很可能是由于不良设计引起的递归查询失败所致。针对这种情况建议按照官方文档指示修正 compose manifest ,即增加字段 `"dns_search : ."` 来强制限定搜索域范围仅限当前子网内的资源对象。 --- ### 总结 综上所述,要彻底消除因 `Connection Refused` 而阻碍成功的登陆行为可以从以下几个角度切入处理:一是核查物理链路畅通状况排除硬件层面干扰因素;二是依据实际需求灵活运用策略规避不必要的安全隐患同时兼顾便利程度;三是密切跟踪后台运作细节快速捕捉蛛丝马迹进而采取针对性补救措施。
评论 9
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值