Android SDK更新 Connection to http://dl-ssl.google.com refused 解决方法

解决Android SDK更新问题:使用http协议替代https
本文提供了解决在中国大陆使用SDKManager更新Android SDK遇到的问题的方法,包括配置VPN、使用http协议替代https协议、直接下载文件以及修改hosts文件等解决方案。
问题描述

使用SDK Manager更新时出现问题
Failed to fetch URL https://dl-ssl.google.com/android/repository/repository-6.xml, reason: Connection to https://dl-ssl.google.com refused
Failed to fetch URL http://dl-ssl.google.com/android/repository/addons_list-1.xml, reason: Connection to http://dl-ssl.google.com refused
Failed to fetch URL https://dl-ssl.google.com/android/repository/addons_list-1.xml, reason: hostname in certificate didn't match: <dl-ssl.google.com> != <www.google.com>
更新ADT时无法解析https://dl-ssl.google.com/android/eclipse


解决办法

由于某些众所周知又无法理解的原因,我们大陆使用Google的服务会出现种种问题,譬如Android开发也会出现阻碍。不过首先要说明的是一般情况下使用SDK Manager更新或者更新Eclipse的ADT插件是没有问题的,我以前也能正常更新,但是昨天不知道节点抽什么风,压根无法连接服务器,出现了上边的种种问题,下面说一下如果网络抽风的话应该如何解决问题。

第一种方法一劳永逸,直接配置VPN,但是现在想找个速度快又稳定还免费的VPN实在不易,尤其是更新SDK,以几kb/s的速度一个文件需要400多分钟,所以也就放弃了VPN。

另一种方法是使用http协议而不是https协议,因为https协议进行了加密处理,大陆因为无法审查,直接封死,而http协议则进行过滤处理,如果不访问乱七八糟的东西,更新个SDK还是没问题的。
在SDK Manager下Tools->Options打开了SDK Manager的Settings,选中“Force https://… sources to be fetched using http://…”,强制使用http协议。
而在更新ADT插件的时候则使用网址http://dl-ssl.google.com/android/eclipse,而不是https://dl-ssl.google.com/android/eclipse,这个在官方开发文档里也有介绍。
但是昨天的情况就是使用http协议也无法访问。

再说一个比较麻烦的方法,就是直接打开
https://dl-ssl.google.com/android/repository/addons_list.xml
https://dl-ssl.google.com/android/repository/repository.xml
https://dl-ssl.google.com/android/repository/addon.xml
这几个文件,找到你要下载的文件名,直接用迅雷下载,ADT可以直接在官网下载ADT包进行安装。具体方法自己搜索。

最好的方法还是改hosts文件的方法,更新速度较快。Windows在C:\WINDOWS\system32\drivers\etc目录下,Linux用户打开 /etc/hosts文件。
打开文件后添加以下内容。

#Google主页
203.208.46.146 www.google.com
#这行是为了方便打开Android开发官网 现在好像不翻墙也可以打开
74.125.113.121 developer.android.com
#更新的内容从以下地址下载
203.208.46.146 dl.google.com

203.208.46.146 dl-ssl.google.com


本文转自 http://blog.youkuaiyun.com/foxeatapple/article/details/8450372

### 问题分析 在 Nginx 与 PHP-FPM 的通信过程中,出现 `connect() to unix:/tmp/php-cgi-73.sock failed (111: Connection refused)` 错误,通常表示 Nginx 尝试通过 Unix 域套接字连接 PHP-FPM 时被拒绝。该问题可能由多个因素引起,包括 PHP-FPM 未启动、套接字文件权限配置错误、路径不一致、或高并发场景下的资源竞争问题。 --- ### 解决方案 #### 1. 检查 PHP-FPM 是否正常运行 确保 PHP-FPM 服务处于运行状态,并且配置文件中定义的 Unix 套接字路径与 Nginx 配置中使用的路径一致。 可通过以下命令检查服务状态: ```bash systemctl status php-fpm ``` 若服务未运行,使用以下命令启动: ```bash systemctl start php-fpm ``` #### 2. 验证 Nginx 与 PHP-FPM 的套接字路径一致性 在 Nginx 的 `fastcgi_pass` 指令中指定的 Unix 套接字路径应与 `php-fpm.conf` 或 `www.conf` 中的 `listen` 指令一致。例如: ```nginx fastcgi_pass unix:/tmp/php-cgi-73.sock; ``` 对应的 `www.conf` 应包含: ```ini listen = /tmp/php-cgi-73.sock ``` #### 3. 检查套接字文件权限 Unix 套接字文件的权限需确保 Nginx 进程有读写权限。可在 `www.conf` 中配置用户和组: ```ini user = nginx group = nginx listen.owner = nginx listen.group = nginx listen.mode = 0660 ``` 修改后重启 PHP-FPM: ```bash systemctl restart php-fpm ``` #### 4. 处理高并发场景下的资源限制 在高并发环境下,Unix 域套接字可能出现资源不足问题,表现为 `Resource temporarily unavailable` 错误[^3]。可尝试以下优化措施: - **调整 PHP-FPM 的 `pm.max_children`**:确保能够处理最大并发请求。 - **增加 `pm.start_servers` 和 `pm.min_spare_servers`**:提升初始并发能力。 - **使用 TCP 代替 Unix 域套接字**(如性能允许): ```nginx fastcgi_pass 127.0.0.1:9000; ``` 并在 `www.conf` 中设置: ```ini listen = 127.0.0.1:9000 ``` #### 5. 检查文件描述符限制 高并发场景下,系统或用户级别的文件描述符限制可能不足,导致连接失败。可使用以下命令查看当前限制: ```bash ulimit -n ``` 若值较低(如 1024),建议在 `/etc/security/limits.conf` 中调整: ```conf nginx soft nofile 65535 nginx hard nofile 65535 ``` 同时在 `/etc/nginx/nginx.conf` 中设置: ```nginx worker_rlimit_nofile 65535; ``` #### 6. 日志分析与调试 查看 Nginx 和 PHP-FPM 的日志以获取更详细的错误信息: ```bash tail -f /var/log/nginx/error.log tail -f /var/log/php-fpm/www-error.log ``` 日志中可能包含如 `connect() to unix:/tmp/php-cgi-73.sock failed (111: Connection refused)` 的具体上下文,有助于定位问题。 --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值