企业官网建设流程全解析

简介：这份文档面向Android应用开发者，尤其是初次接触Android Studio、需要从官方渠道获取SDK组件却受限于网络速度的初中级开发者，聚焦于SDK Manager中代理设置这一具体操作场景，帮助解决SDK包及Gradle插件、Google服务框架等依赖下载缓慢、频繁中断的问题。资源包内仅含1个docx文档，压缩包约102KB，篇幅精简，便于随查随用。文档围绕SDK Manager的入口路径与代理配置项展开，涉及Tools菜单进入SDK Manager、齿轮设置按钮、HTTP Proxy中的自动检测与手动配置两种模式，以及Host、Port、用户名密码等字段的填写要点，并提及国内镜像站点作为代理源的选用思路。已有861人学习下载，说明该操作在开发者群体中具有普遍需求。读者可据此快速完成代理配置，提升组件下载速度与稳定性，并在网络环境变化时知道如何调整或取消代理，减少环境搭建阶段的等待与反复尝试。

1. SDK 设置代理：为什么你改了 Host 还是连不上

Android Studio 里点开 SDK Manager，进度条卡在 0% 不动，或者下载到一半报Connection reset，这是很多人第一次配 Android 开发环境时的固定节目。SDK 设置代理这件事本身不复杂，难的是配完之后到底有没有生效、哪些流量走了代理、哪些没走。我见过太多人把 Host 填进去、端口写 80、点 Apply，然后回到主界面继续卡着，最后怀疑是镜像站挂了——其实八成是配置层级搞错了。

这篇笔记围绕 SDK Manager 里的代理配置展开，把「在哪配、配什么、怎么验证、什么时候该撤」这条链路拆开讲。适合两类人：一是刚装完 Android Studio、SDK 组件下不动的开发者；二是环境已经能跑、但想搞清楚 Gradle 依赖和 SDK 下载为什么表现不一致的熟手。读完你应该能自己判断一次下载失败到底是代理没生效、镜像源不对，还是本地缓存和校验在捣乱。

2. SDK Manager 代理配置：从入口到生效的完整链路

2.1 先分清三层网络配置，别在错误的层动手

Android 开发环境里跟「下载」相关的网络配置至少有三层，很多人翻车是因为把三层的职责混在一起了。

第一层是 IDE 自身的 HTTP Proxy，位置在 Settings 里的 Appearance & Behavior → System Settings → HTTP Proxy。这一层管的是 IDE 插件市场、部分内置更新检查。第二层是 SDK Manager 自己的代理设置，入口在 SDK Manager 窗口里的齿轮图标，也就是项目正文里提到的那条路径。这一层专门管 SDK 平台包、Build-Tools、Platform-Tools、模拟器镜像这些组件的下载。第三层是 Gradle 的依赖下载，它走的是gradle.properties里的systemProp.http.proxyHost系列参数，或者项目级仓库配置，跟 SDK Manager 完全是两套东西。

常见做法是：SDK 组件下不动，先动第二层；Gradle 同步失败，去动第三层；IDE 插件装不上，才看第一层。把这三层分开之后，排查范围立刻缩小一半。我一般会在改配置前先确认当前卡住的是哪一步——是 SDK Manager 列表都刷不出来，还是列表出来了但下载进度不动，这两种现象指向的层不一样。

2.2 手动配置 Host 与 Port 的具体操作

打开 Android Studio，菜单栏 Tools → SDK Manager，等窗口加载出来。左下角能看到 SDK Platforms、SDK Tools、SDK Update Sites 几个标签页，右上角有一个齿轮图标，点它弹出 SDK Manager Settings。

在设置窗口里找到 HTTP Proxy 区域，有两个单选：Auto-detect proxy settings 和 Manual proxy configuration。自动检测在部分网络环境下能识别系统级配置，但识别结果不透明，出问题时你根本不知道它用了什么。所以只要不是一次就通，直接切到手动模式。

手动模式下要填的字段如下：

填完点 Apply 或 OK，设置窗口关闭。这里有个细节：SDK Manager 的代理设置是持久化到 IDE 配置目录里的，不是只对当前会话生效，所以改错了要记得回来改回去，否则下次打开还是错的。

2.3 用 SDK Update Sites 验证代理是否真的通了

配完代理直接回主界面看下载速度，是最容易误判的做法。更可靠的方式是先看 SDK Update Sites 标签页。

这个标签页列出的是 SDK Manager 当前使用的下载源地址。正常情况下应该能看到若干条以https://开头的源。如果你配了代理但这里显示的源地址还是官方域名，说明代理只作用于连接层、没有替换源，那么下载慢的问题可能依然存在——代理解决的是「怎么连过去」，镜像源解决的是「从哪拿文件」，两者不是一回事。

验证顺序我一般这么走：先在 SDK Update Sites 里确认源地址列表是否可访问，再回到 SDK Platforms 勾一个体积小的组件（比如某个旧版本的 Platform，几百 MB 以内），点 Apply 观察进度。如果进度条能稳定往前走，说明代理链路通了；如果立刻报错，看报错文本里的状态码，407是代理认证问题，502/504是镜像站侧的问题，Connection timed out多半是 Host 或 Port 填错。

2.4 命令行侧怎么确认代理生效

图形界面之外，命令行工具的行为更能说明问题。sdkmanager命令行工具读取的代理配置来源和 IDE 不完全一致，它主要看环境变量和~/.android/下的配置。

# 查看当前 shell 里是否已有代理相关环境变量 env | grep -i -E "http_proxy|https_proxy|no_proxy" # 用 sdkmanager 列出已安装和可安装的包，能列出来说明网络链路基本通 sdkmanager --list # 只看已安装的包，输出更短，适合快速验证 sdkmanager --list_installed

第一段命令用来排除干扰：如果 shell 里已经设了http_proxy，那么sdkmanager会优先用它，可能跟你刚在 IDE 里配的完全不是一回事，这时候你在 IDE 里怎么改都「没效果」。第二段--list会实际发起网络请求去拉包列表，能正常输出就说明至少元数据请求通了。第三段适合在--list输出太长时快速确认本地状态。

参数上要注意，sdkmanager的--list不带任何过滤时会拉全量列表，网络差的时候会等很久，可以先加--channel=0只看稳定通道。另外sdkmanager的路径通常在$ANDROID_HOME/cmdline-tools/latest/bin/下，如果提示找不到命令，先确认ANDROID_HOME和PATH有没有配好，这跟代理是两码事，别混在一起排查。

3. 镜像源与代理的配合：Host 填对了为什么还是慢

3.1 代理和镜像源解决的是两个不同问题

这是最容易混淆的一点。代理配置里的 Host 字段，严格来说填的是一个「代理服务器地址」，SDK Manager 会把请求发给它，由它转发。而项目正文里给的mirrors.neusoft.edu.cn这类地址，本质上是镜像站点，它直接提供文件内容。

当你在 SDK Manager 的 HTTP Proxy 里填一个镜像站域名时，实际效果取决于这个站点是否同时提供代理服务。有些镜像站两者都提供，填进去就能用；有些只提供文件下载、不提供代理转发，填进去就会出现「能连上但拿不到正确响应」的怪现象。这就是为什么有人照着教程填完 Host 依然卡住——不是步骤错了，是那个地址在当前场景下的角色不对。

更稳的思路是分两条路走：一条是代理链路，填真正可用的代理地址；另一条是源替换，通过 SDK Update Sites 或者环境变量把下载源指向镜像。两条路各自独立，哪条通就用哪条，不要指望一个 Host 字段同时干两件事。

3.2 通过环境变量切换下载源

命令行侧切换源比图形界面更直接。sdkmanager支持通过--sdk_root指定 SDK 目录，但源地址的覆盖更多依赖仓库配置。一个常见做法是维护一份自定义的仓库配置，把默认源替换成镜像源。

# 备份默认的仓库配置文件（如果存在） cp ~/.android/repositories.cfg ~/.android/repositories.cfg.bak 2>/dev/null # 设置 SDK 根目录，后续命令都基于它 export ANDROID_HOME="$HOME/Android/Sdk" export PATH="$ANDROID_HOME/cmdline-tools/latest/bin:$PATH" # 指定 channel 为稳定通道，避免拉到预览版组件 sdkmanager --list --channel=0

第一段备份是后悔药，改配置前先留一份，出问题能退回去。第二段设置ANDROID_HOME和PATH，这是所有命令行工具能找到彼此的前提，很多人sdkmanager报错其实是路径没配。第三段--channel=0限定稳定通道，能减少列表体积、加快验证速度。

需要说明的是，不同版本的命令行工具对源覆盖的支持程度不一样，有的版本认--proxy参数，有的只认环境变量。如果你在某个版本上发现参数不生效，先sdkmanager --help看一眼当前版本实际支持哪些选项，别硬套网上的命令。

3.3 组件下载失败时先看本地缓存

代理配好、源也换了，还是有个别组件反复失败，这时候问题往往不在网络，而在本地缓存。SDK 下载的临时文件和已下载包会落在$ANDROID_HOME下的特定目录里，残留的临时文件会让重试一直失败。

# 查看 SDK 目录下各子目录占用，定位异常大的临时目录 du -sh "$ANDROID_HOME"/* 2>/dev/null | sort -h # 查看临时下载目录内容（路径随版本略有差异，常见为 .temp 或 temp） ls -la "$ANDROID_HOME/.temp" 2>/dev/null || ls -la "$ANDROID_HOME/temp" 2>/dev/null

第一段按体积排序，能快速看出哪个组件目录异常膨胀，通常是下载中断留下的半成品。第二段确认临时目录里有没有残留文件。处理方式是删掉对应组件的临时文件后重试，而不是整个 SDK 目录推倒重来——后者代价太大，而且会把已经能用的组件一起干掉。

这里有个血泪经验：删临时文件之前先确认没有正在运行的下载任务，IDE 和命令行同时操作同一个 SDK 目录时，删文件可能让正在进行的任务报更奇怪的错。

4. 避坑与排查：五条真实踩坑记录

4.1 现象：Apply 之后下载速度毫无变化

原因：改的是 IDE 全局 HTTP Proxy，不是 SDK Manager 自己的代理设置。两层入口长得像，但作用范围不同，全局那层不接管 SDK 组件下载。

解决：回到 SDK Manager 窗口，点右上角齿轮进设置，确认改的是这个弹窗里的 HTTP Proxy 区域。改完关掉 SDK Manager 重新打开，让配置重新加载。

4.2 现象：报 407 或提示需要认证

原因：镜像站或代理要求身份验证，但 Username / Password 留空，或者填了但没勾选需要认证的选项。

解决：先确认该地址是否真的需要认证。公共镜像一般不需要，如果确实需要，把凭据填进对应字段。注意凭据是明文存在 IDE 配置里的，共用机器上要留意这一点。

4.3 现象：列表能刷出来，单个组件下载到 99% 失败

原因：大文件下载对连接稳定性要求高，中途断开后临时文件残留，重试时校验不通过。

解决：按 3.3 的思路清掉该组件的临时文件再重试。如果反复在同一位置失败，换一个体积更小的同类组件先验证链路，排除是单个包的问题还是整体链路的问题。

4.4 现象：命令行sdkmanager完全不走 IDE 里配的代理

原因：命令行工具读环境变量和独立配置文件，不读 IDE 的图形配置。shell 里已有的http_proxy会覆盖其他设置。

解决：用 2.4 的第一段命令确认环境变量现状，需要时在 shell 里显式 export 对应变量，或者临时 unset 掉冲突的变量再跑命令。IDE 和命令行要当成两套环境分别配。

4.5 现象：换了镜像源之后 Gradle 同步依然失败

原因：Gradle 依赖走的是gradle.properties和项目仓库配置，跟 SDK Manager 的源是两套体系。SDK 源换了不代表 Gradle 源换了。

解决：单独检查项目根目录gradle.properties里的代理参数和settings.gradle里的仓库地址。这两处跟 SDK 代理互不影响，别指望改一处全通。

5. 进阶：把代理配置做成可切换的脚本

配一次代理不难，难的是在不同网络环境之间来回切。我后来的做法是把 SDK 相关的环境变量和源配置收进一个小脚本，需要时 source 一下，不用每次翻 IDE 设置。

#!/usr/bin/env bash # sdk-env.sh：按需切换 SDK 下载环境，source 后生效 # 基础路径，按本机实际安装位置改 export ANDROID_HOME="$HOME/Android/Sdk" export PATH="$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$PATH" # 用法：source sdk-env.sh mirror 走镜像，source sdk-env.sh direct 走直连 case "$1" in mirror) # 镜像环境：清掉可能冲突的旧变量，再设新的 unset http_proxy https_proxy export SDK_MIRROR_MODE=1 echo "SDK 环境：镜像模式" ;; direct) unset http_proxy https_proxy unset SDK_MIRROR_MODE echo "SDK 环境：直连模式" ;; *) echo "用法：source sdk-env.sh [mirror|direct]" ;; esac

这段脚本的关键在unset那两行。切换环境时最怕旧变量残留，mirror和direct两个分支都先清掉http_proxy和https_proxy，避免上一次的设置阴魂不散。SDK_MIRROR_MODE这个自定义变量本身不参与网络请求，只是给后续脚本或提示用的标记，你可以按自己的习惯换成别的名字。

验证脚本是否生效，source 之后跑一遍env | grep -i proxy和sdkmanager --list_installed，前者确认变量状态符合预期，后者确认工具链能找到。两个都正常，再去做实际的组件下载。

还有一个容易被忽略的点：IDE 是从桌面环境启动的，它继承的环境变量跟你终端里 source 过的不是同一份。所以脚本管命令行，IDE 里的图形配置单独维护，两边各记各的，别指望脚本能改到 IDE 的设置。我一般会在脚本注释里写清楚「本脚本仅影响当前 shell」，省得下次自己都记混。

从那以后我每次动 SDK 网络配置，都强制走一遍「先看环境变量、再确认改的是哪一层、最后用小体积组件验证」这三步，不再凭感觉点 Apply。希望帮到你。

本文还有配套的精品资源，点击获取