简介：Nexus 3.30.0-01 的 Windows 64 位安装包，面向需要在本地或企业内网搭建 Maven 仓库的 Java 开发者与运维人员，用于解决依赖下载慢、组件发布分散、仓库权限难统一等问题。压缩包约 212.01MB，内含 sonatype-work 与 nexus-3.30.0-01 两部分：前者承载运行时数据与配置，后者为可执行程序及 conf 下的 nexus.properties 等启动配置，解压后即可按官方文档完成部署。该版本集成代理仓库缓存、多格式存储库聚合、组件发布、细粒度访问控制与构件质量校验等能力，并可与 Jenkins、GitLab CI/CD 衔接，支撑 SNAPSHOT 版本迭代与持续集成流程。已有 1792 人学习下载，适合希望自建私服、规范依赖管理并提升构建效率的团队参考实践。
1. 从一台被 Nexus 拖垮的构建机说起
上周帮一个小组收拾构建机，磁盘报警，翻到/opt下面一个 nexus 目录，占了快 40G，日志文件单个就 3G 多。问下来是半年前有人装了个 nexus-3.30.0-01-win64.zip 解压即用的版本，装完就没人管过，仓库里堆了几百个快照包，清理任务从来没配。这类事在中小团队里太常见了：Nexus 作为 Maven、npm、Docker 的私服入口，装的时候觉得解压就能跑，真出问题的时候才发现 JVM 参数、存储路径、清理策略一个都没调。这篇记录的是我在 Windows 环境下把 nexus-3.30.0-01-win64.zip 从解压到跑通、再到能长期稳定运行的完整过程，包括版本选择、目录规划、服务注册、仓库配置和几个我踩过的坑。适合第一次搭私服的新手照着走，也适合已经装过但没配好的熟手对照排查。
2. 装前把环境列清楚：JDK、目录与端口三件事
2.1 版本与 JDK 的对应关系
nexus-3.30.0-01-win64.zip 这个包名里已经写明了平台和版本：3.30.0-01，Windows 64 位。这个版本属于 Nexus Repository Manager 3.x 的 OSS 版本，自带 Jetty 容器，不需要额外装 Tomcat。但它对 JDK 有硬性要求，3.30 这一代要求 JDK 8 或 JDK 11，我一般统一用 JDK 8u202 之后的 8 版本，兼容性最稳。如果你机器上装的是 JDK 17，启动脚本会在校验阶段直接退出，报Unsupported Java version，这不是配置问题，是版本不匹配，换 JDK 就行。
装之前先确认两件事：一是java -version输出的位数要和系统一致，64 位系统配 64 位 JDK；二是JAVA_HOME要指向 JDK 根目录而不是bin目录。常见做法是在系统环境变量里加一条JAVA_HOME=C:\Program Files\Java\jdk1.8.0_202，再把%JAVA_HOME%\bin追加到Path前面。改完开一个新的 cmd 窗口验证，老窗口不会刷新环境变量，这一点新手很容易忽略。
| 项目 | 要求 | 我实际用的 |
|---|---|---|
| 操作系统 | Windows 64 位 | Windows Server 2019 |
| JDK | 8 或 11 | JDK 8u202 |
| 内存 | 建议 4G 以上 | 8G |
| 磁盘 | 系统盘外单独数据盘 | D 盘 200G |
| 端口 | 8081 默认 | 8081 |
2.2 目录规划：别把数据放在解压目录里
Nexus 的目录结构里有两个关键位置：安装目录（解压出来的nexus-3.30.0-01）和数据目录（默认在安装目录同级的sonatype-work）。很多人图省事直接解压到C:\nexus，结果数据也跟着长在 C 盘，半年后系统盘爆满。我一般会这样分：
D:\nexus\nexus-3.30.0-01 # 程序目录，只放安装文件 D:\nexus-data # 数据目录，blob、日志、配置都在这数据目录通过nexus.vmoptions里的-Dkaraf.data指定，或者更简单，在bin\nexus.vmoptions里改-Djava.io.tmpdir和存储路径。3.30 版本默认数据目录是..\sonatype-work\nexus3，如果你把安装目录放在D:\nexus\nexus-3.30.0-01，数据就会落在D:\nexus\sonatype-work\nexus3，这个路径可以接受，但建议单独建一个nexus-data目录并做软链接或者改配置，方便以后备份和迁移。
2.3 端口与防火墙
默认端口 8081，如果这台机器上还跑着别的服务，先netstat -ano | findstr 8081看一眼有没有占用。改端口在etc\nexus.properties里改application-port=8081这一行。改完记得在 Windows 防火墙里放行对应端口，内网访问的话入站规则加一条 TCP 端口即可。我遇到过装完本机localhost:8081能开、同事访问不了的情况，九成是防火墙没放行，不是 Nexus 的问题。
3. 解压、启动与首次登录：nexus-3.30.0-01 的落地步骤
3.1 解压与目录检查
把 nexus-3.30.0-01-win64.zip 解压到D:\nexus\，解压后应该看到nexus-3.30.0-01和sonatype-work两个目录（如果压缩包里带了的话）。进入nexus-3.30.0-01\bin，里面有几个关键文件：nexus.exe、nexus.vmoptions、nexus.properties（在etc下）。先别急着双击nexus.exe，那个是服务管理用的，直接跑会闪退。正确的启动方式是开 cmd，cd 到 bin 目录，执行：
cd /d D:\nexus\nexus-3.30.0-01\bin nexus.exe /run/run参数表示前台运行，日志直接打在控制台，第一次装强烈建议用这个方式，能看到启动过程中的所有报错。等看到Started Sonatype Nexus OSS 3.30.0-01这行，说明起来了。这时候别关窗口，另开一个浏览器访问http://localhost:8081。
3.2 首次登录与 admin 密码
3.30 版本的初始密码不在admin.password文件里了（那是 3.17 之前的老做法），而是放在数据目录下的admin.password文件，路径是D:\nexus\sonatype-work\nexus3\admin.password。用记事本打开，里面是一串随机字符串，复制出来，用户名admin，登录后会强制你改密码。改完密码这个文件会自动删除，所以第一次登录前先备份一份，免得手滑改错了找不回来。
提示：如果
admin.password文件不存在，说明数据目录被初始化过或者路径不对，检查nexus.vmoptions里的-Dkaraf.data指向哪里，去那个目录下找。
3.3 注册为 Windows 服务
前台跑通之后，按 Ctrl+C 停掉，改成服务方式常驻。在 bin 目录下执行：
nexus.exe /install nexus nexus.exe /start nexus/install后面的nexus是服务名，可以自定义。装完用services.msc能看到这个服务，启动类型默认是手动，改成自动。这里有个细节：服务方式启动时用的是nexus.vmoptions里的 JVM 参数，而不是系统环境变量里的JAVA_HOME，所以如果服务启动失败但前台能跑，八成是nexus.vmoptions里的-Xms、-Xmx设得太大或者 JDK 路径没写对。我一般把-Xms1024m -Xmx1024m改成-Xms2048m -Xmx2048m，小团队够用，机器内存大的可以往上加，但别超过物理内存的一半。
3.4 验证服务状态
服务起来后，用两个命令确认：nexus.exe /status看服务状态，curl http://localhost:8081/service/rest/v1/status看应用状态。后者返回{"healthy":true}才算真正可用。只看服务在运行不够，有时候服务进程活着但应用没起来，比如数据目录权限不对、端口被占，这时候status接口会超时或者返回 503。
4. 仓库配置：Maven、npm 与清理策略
4.1 创建代理仓库与宿主仓库
登录后进Settings > Repository > Repositories，点Create repository。Maven 场景一般建三个：maven-central（proxy 类型，指向中央仓库）、maven-releases（hosted 类型，放正式包）、maven-snapshots（hosted 类型，放快照包）。proxy 仓库的 Remote storage 填https://repo1.maven.org/maven2/，这个地址在 3.30 版本里是预置的，直接选maven-central模板就行。
npm 场景建一个npm-proxy指向https://registry.npmjs.org，再建一个npm-hosted放内部包。Docker 场景需要额外开一个端口，在nexus.properties里加application-port-ssl或者用独立的 connector，这个稍微复杂，建议先把 Maven 和 npm 跑通再动 Docker。
4.2 清理策略：别让 blob 无限长
这是我最想强调的一步。Nexus 默认不会自动清理快照包，maven-snapshots仓库如果不配清理策略，几个月就能堆出几十 G。在Repository > Cleanup Policies里新建一条：Format选maven2，Policy type选Age，Maximum age设 30 天，Criteria里勾上Release type = Snapshot。然后在maven-snapshots仓库的Cleanup选项卡里绑定这条策略。
# 清理任务需要手动触发或配成定时任务 # 在 Settings > Tasks 里创建 Admin - Cleanup repositories 任务 # 频率设成每天凌晨 2 点任务配好后，第一次手动 Run 一次，观察日志里Deleted X components的数量，确认策略生效。我见过配了策略但没建任务的，策略只是规则，任务才是执行者，两个都要有。
4.3 客户端指向私服
Maven 的settings.xml里加 mirror：
<mirror> <id>nexus</id> <mirrorOf>*</mirrorOf> <url>http://192.168.1.10:8081/repository/maven-public/</url> </mirror>maven-public是 Nexus 默认建的 group 仓库，把 proxy 和 hosted 聚合在一起，客户端只认这一个地址就行。npm 的话在.npmrc里写registry=http://192.168.1.10:8081/repository/npm-public/。配完跑一次mvn clean package或者npm install，看 Nexus 的Browse里有没有新包进来，有就说明链路通了。
5. 避坑记录：五个让我返工的问题
5.1 服务启动报JAVA_HOME is not defined
现象是nexus.exe /start之后服务立刻停止，日志里写JAVA_HOME is not defined correctly。原因是服务方式启动不读用户环境变量，只读系统变量，而且nexus.vmoptions里如果没显式指定-Djava.home，它会去找JAVA_HOME。解决方式是把JAVA_HOME加到系统变量（不是用户变量），或者在nexus.vmoptions里加一行-Djava.home=C:\Program Files\Java\jdk1.8.0_202。改完重启服务。
5.2 8081 端口被占用但 netstat 查不到
现象是启动日志报Address already in use，但netstat -ano | findstr 8081什么都没有。原因是端口被 Hyper-V 或者 WSL 的保留端口段占了，Windows 的netsh interface ipv4 show excludedportrange protocol=tcp能看到保留区间。解决办法是换端口，比如改成 8082，或者用net stop winnat释放保留段（不推荐，会影响其他服务）。我一般直接换端口，省事。
5.3 上传包报 413 Request Entity Too Large
现象是mvn deploy大包时返回 413。原因是 Nexus 前面的反向代理（如果有）限制了请求体大小，或者 Nexus 自身的nexus.properties里没调。3.30 版本默认没有请求体限制，但如果套了 Nginx，需要在 Nginx 里加client_max_body_size 500m;。纯 Nexus 直连的话检查etc\nexus.properties里有没有nexus.request.body.limit之类的配置，没有就不用管。
5.4 数据目录权限导致启动卡住
现象是服务显示运行中，但 8081 一直连不上，日志停在Initializing。原因是数据目录sonatype-work的权限不对，服务账户没有写权限。解决方式是把数据目录的完全控制权限给NETWORK SERVICE或者运行服务的账户，右键属性 > 安全 > 编辑 > 添加。这个坑在把数据目录放到 D 盘或者网络盘时特别常见。
5.5 忘记 admin 密码
现象是改完密码后忘了，admin.password文件已经删了。解决办法是停服务，删掉数据目录下的db目录（会丢失所有配置和仓库数据，慎用），重启后会重新生成admin.password。如果不想丢数据，3.30 版本没有官方的密码重置命令，只能走删库这条路。所以我一般装完第一件事就是把初始密码记到密码管理器里，改密码的时候也同步更新。
6. 装完怎么验证：三个必须跑通的检查
装完不等于跑通，我一般用三个检查确认这套 Nexus 真的能用。第一个是状态接口，curl http://localhost:8081/service/rest/v1/status返回{"healthy":true}，这个只能说明应用起来了，不能说明仓库能用。第二个是实际拉包，找一台客户端机器，配好settings.xml的 mirror，跑mvn dependency:get -Dartifact=org.slf4j:slf4j-api:1.7.30，看能不能从私服拉到，拉到了去 Nexus 的Browse > maven-central里搜slf4j-api，能看到缓存记录就说明 proxy 链路通了。第三个是推包，本地随便建个 Maven 项目，mvn deploy到maven-snapshots，然后去Browse里确认包在，再删掉本地.m2里的缓存重新拉一次，能拉回来才算闭环。
| 检查项 | 命令/操作 | 通过标准 |
|---|---|---|
| 应用状态 | curl .../service/rest/v1/status | 返回 healthy:true |
| 代理拉取 | mvn dependency:get | 本地仓库有包，Nexus 有缓存 |
| 宿主推送 | mvn deploy | Browse 里能看到构件 |
| 清理任务 | 手动 Run 一次 | 日志有 Deleted 记录 |
还有一个小技巧：把nexus.vmoptions里的日志级别调一下，默认的-Dkaraf.log.console=INFO在排查问题时不够用，临时改成DEBUG能看到更多细节，排查完记得改回来，不然日志涨得飞快。另外定期看一眼sonatype-work\nexus3\log\nexus.log的大小，超过 500M 就配个日志轮转，Windows 下没有 logrotate，我一般用任务计划程序写个脚本定期清空或者归档。
从那以后我每次装 Nexus，不管多急，都会先把数据目录单独分出来、把清理策略和任务配好、把初始密码记下来，这三件事做完才敢让同事连上来。希望帮到你。
本文还有配套的精品资源，点击获取
