简介：Nexus 3.45.0-01 Windows 64 位版是面向 Java 开发、DevOps 与企业研发团队的 Maven 私服搭建包，用于集中管理内部组件、第三方依赖及公共仓库缓存，缓解直连中央仓库的速度与安全问题。压缩包共 690 个文件、约 240.62MB，含 420 个 jar 核心库、82 个 dll 与 22 个 exe 运行组件，以及 29 个 xml、19 个 properties 等配置；目录区分 nexus-3.45.0-01 程序文件与 sonatype-work 运行数据，后者包含配置、日志和存储内容。已有 417 人学习下载，适合需要落地本地私服、理解仓库代理/发布/权限控制机制并维护目录结构的开发者参考。
1. 内网里那堆 jar，总得有个地方放
第一次见到这个包是在一台 Windows 构建机上：几个项目共用同一批内部 jar，每个人本地拿mvn install:install-file装一遍，版本对不齐就开始互相甩锅，有人升了 0.3.2 有人还是 0.3.0，打出来的包跑起来行为都不一样。想搭个 maven 私服，又不想为这点事在内网里折腾一台 Linux 加容器编排，于是就有了 nexus-3.45.0-01-win64 这种 Windows 免安装包——解压、改两行配置、注册成服务，8081 端口起来之后，代理中央仓库、存内部构件、对外聚合成一个地址，三件事一次办完。它适合的场景很具体：内网团队、Windows 机器承担构建、人数在几人到几十人之间、暂时没有独立的构件管理平台。下面按我实际落地的顺序,从解包一路写到备份和升级。
2. 从 zip 到 8081 端口：Windows 上的启动顺序
2.1 解压位置和 Java 前置检查
Windows 上最容易翻车的第一步不是配置，是解压到哪。放到C:\Program Files\下面会同时踩两个坑：路径带空格，部分脚本调用时参数被截断；目录受 UAC 保护，注册成服务后以系统账户跑，写sonatype-work时权限不对。我一般的做法是单独建一个盘符目录，比如D:\nexus\，包解开之后同级会多出一个sonatype-work，所有数据、日志、blob 都在里面，这个目录将来就是备份对象。
Java 是硬前置。3.45 这条线上 Java 8 和 Java 11 都能跑，我倾向 11，主要是 GC 行为和 TLS 握手在新一点的环境里更省心。注意必须是 JDK 而不是 JRE，也不要把JAVA_HOME指到bin子目录。
# 机器级和用户级分开看，注册成服务后读的是机器级 [Environment]::GetEnvironmentVariable("JAVA_HOME","Machine") [Environment]::GetEnvironmentVariable("JAVA_HOME","User") # 解压到无空格路径 Expand-Archive -Path .\nexus-3.45.0-01-win64.zip -DestinationPath D:\nexus Get-ChildItem D:\nexus # 验证 java 能被 JDK 目录下的可执行文件拉起 & "$env:JAVA_HOME\bin\java.exe" -version[Environment]::GetEnvironmentVariable的第二个参数是关键，Machine读的是系统变量，User读的是当前登录用户变量。这两者经常不一致：命令行里java -version正常，服务却起不来，原因就是服务以 LocalSystem 身份运行，看不到你个人账户下的变量。Expand-Archive之后Get-ChildItem应该能看到nexus-3.45.0-01这个目录，bin、etc、lib、public都在里面。
2.2 nexus.vmoptions 里值得改的四个参数
bin\nexus.vmoptions是 JVM 启动参数的落点，默认堆给得比较足，小机器上直接跑会把系统内存吃光然后开始频繁 GC，表现为 Web 界面点一下转三秒。需要看的是四项：
| 参数 | 默认量级 | 调整依据 |
|---|---|---|
-Xms/-Xmx | 同值，约 2.7G | 机器 8G 内存给 2G 左右，16G 以上可以维持默认 |
-XX:MaxDirectMemorySize | 与堆同值 | 必须和-Xmx一起调，否则大文件上传会 OOM |
-Djava.io.tmpdir | 系统临时目录 | 指到本地数据盘，别指网络盘或内存盘 |
-Dkaraf.data | 相对路径 | 多实例部署时才改，单实例保持默认 |
-Xms和-Xmx设成一样是为了避免运行期反复扩堆，Nexus 这种常驻服务启动完基本就稳定在某个水位。MaxDirectMemorySize管的是堆外直接内存，构件上传下载走的是 NIO，堆外不够时报的错往往是OutOfMemoryError: Direct buffer memory，看着像堆的问题，其实跟-Xmx没关系，这是血泪经验。-Djava.io.tmpdir指向网络盘或 RAM disk，上传大 jar 时容易出半截文件，排起来非常费劲。
# D:\nexus\nexus-3.45.0-01\bin\nexus.vmoptions（节选） -Xms2048m -Xmx2048m -XX:MaxDirectMemorySize=2048m -XX:+UnlockDiagnosticVMOptions -Djava.io.tmpdir=D:\\nexus\\tmp注意 ini 文件里 Windows 路径要写双反斜杠或者正斜杠，单反斜杠会被当成转义。改完这个文件必须重启进程才生效，热改没用。
2.3 先前台跑通，再注册成服务
我见过太多人上来就nexus.exe /install，服务装上了、起不来、日志也找不到，然后开始怀疑包有问题。正确顺序是先前台跑，看到 Jetty 起监听再加服务。前台模式的好处是所有启动日志直接打在控制台，出错一眼能看见。
cd D:\nexus\nexus-3.45.0-01\bin # 前台启动，Ctrl+C 退出 .\nexus.exe /run # 看到 Started Sonatype Nexus 之后再开另一个窗口验证 Invoke-WebRequest -Uri http://localhost:8081/ -UseBasicParsing/run是前台参数，进程退出即服务停止，适合调试。确认能起来之后，用管理员权限的 PowerShell 执行注册：
# 注册服务，服务名默认 nexus .\nexus.exe /install nexus # 启动 / 查询 / 停止 .\nexus.exe /start nexus Get-Service nexus .\nexus.exe /stop nexus # 彻底卸载 .\nexus.exe /uninstall nexus/install后面的名字是服务显示名，多实例共存时必须区分开。注册完之后，服务的启动账户默认是 LocalSystem，如果你前面只配了用户级JAVA_HOME，这里就会失败。改法是系统属性里加机器级变量，或者在服务属性里把登录账户改成你自己的账户——后者在需要访问网络共享存储时才需要。服务起来以后，命令行窗口可以关掉，日志改到sonatype-work\nexus3\log\nexus.log里看。
2.4 首次登录和端口的三处确认
浏览器打开http://<机器IP>:8081/，右上角登录，账号admin，密码不在任何文档里，它被写在数据目录的一个一次性文件里：
# 首次登录密码位置 Get-Content D:\nexus\sonatype-work\nexus3\admin.password # 改完密码后把这个文件删掉 Remove-Item D:\nexus\sonatype-work\nexus3\admin.password这个密码文件用完即删，留着等于给自己留后门。端口如果被占用（Windows 上 8081 经常被别的调试工具占了），改etc\nexus-default.properties：
application-port=8081 application-host=0.0.0.0application-host改成0.0.0.0才能被局域网其他机器访问，默认只监听本机时同事会报连接超时。改完同样要重启服务。还有一处是防火墙：Windows Defender 防火墙默认拦入站，需要给 8081 开一条入站规则，否则本机通了、别人不通。
注意：端口、host、防火墙三处必须同时确认。只改一处然后排查半天，是最常见的时间浪费。
3. 仓库三分法：proxy、hosted、group 各管什么
3.1 proxy 仓库把公共依赖搬到内网
proxy 仓库的定位是「缓存转发」。它自己不产生构件，只在你第一次请求某个 jar 时去远端拉，拉回来存一份，第二次同版本请求直接命中本地缓存。这一步对构建速度的提升非常直接：一条mvn clean package里可能有几十次下载，缓存之后基本只剩元数据校验。
新建路径是Server administration and configuration → Repository → Repositories → Create repository → maven2 (proxy)。关键参数只有三个：
| 参数 | 含义 | 取值建议 |
|---|---|---|
| Remote storage | 远端仓库地址 | 公共 Maven 仓库根地址，结尾带斜杠 |
| Maximum component age | 元数据缓存时长 | 1440 分钟，太短会频繁回源 |
| Auto blocking enabled | 远端持续失败时自动熔断 | 开启，避免构建被远端拖死 |
Remote storage填的是仓库根，不是某一个 jar 的地址，末尾斜杠不能省。Maximum component age决定了多久去远端确认一次有没有新版本，设成 0 等于每次构建都回源，缓存就白做了。Auto blocking在远端不可用时把该 proxy 标记为不可用，请求直接走下一个成员，这个开关在内网出口不稳的环境里能省掉大量超时等待。
如果团队有内网可达的公共镜像站，可以把Remote storage换成镜像地址，同步速度会明显好一些；没有就直连公共仓库，日常使用差别主要在首次预热。
3.2 hosted 仓库：release 和 snapshot 必须分家
hosted 仓库放的是自己团队产出的构件。这里有个绕不开的原则：发布版和快照版要建两个仓库，不要塞在一起。
原因在于两者的元数据语义完全不同。快照版本允许同一个版本号反复覆盖，仓库要保留时间戳目录和maven-metadata.xml里的多次记录；发布版本要求版本号唯一且不可变，覆盖就意味着依赖方拿到的内容和昨天不一样，构建结果不可复现。混在一个仓库里，Maven 解析时容易把快照的元数据当成发布的，出现「明明改了代码，拉下来的还是旧包」这种玄学问题。
建两个 maven2 (hosted)，参数差异如下：
| 参数 | maven-releases | maven-snapshots |
|---|---|---|
| Version policy | Release | Snapshot |
| Deployment policy | Disallow redeploy | Allow redeploy |
| Layout policy | Strict | Strict |
Version policy是仓库层面的版本类型断言，Strict布局策略会校验路径结构必须符合 Maven 约定。Disallow redeploy意味着同版本号第二次上传会被拒绝，这是有意为之——它逼着你升版本号而不是悄悄覆盖。快照仓库反过来必须允许覆盖，否则迭代阶段每次都要改版本。
3.3 group 仓库：顺序决定了解析优先级
客户端不应该同时配三个仓库地址。正确做法是建一个 maven2 (group)，把 proxy 和两个 hosted 都拉进来，对外只暴露这一个 URL。
成员顺序是有语义的：Nexus 按顺序查找，前一个找到就不再往后走。常规排法是「自家发布 → 自家快照 → 远端代理」，这样同名构件优先命中内部产出，避免内部包和公共包版本号撞车时拉错。
maven-public (group) ├── maven-releases (hosted, Release) ├── maven-snapshots (hosted, Snapshot) └── maven-central (proxy)调整顺序在 group 的配置页面上拖拽即可，改完不需要重启，但客户端侧有缓存，需要执行一次缓存失效（Invalidate cache）才能立刻看到效果。这一步很多人漏掉，然后以为顺序没生效。
3.4 权限：给发布账号单独开一条路
不要用 admin 去跑 CI 发布。Nexus 的权限模型是基于角色（Role）的，最小可用配置是：建一个角色，只授予两个 hosted 仓库的 browse、read、add、edit 权限，再把角色赋予一个专用用户。
权限串的形态是nx-repository-view-maven2-<仓库名>-<动作>，比如nx-repository-view-maven2-maven-releases-add。只读用户只给read和browse，发布用户再加add和edit。管理员账号只用于配置变更，不进任何流水线变量，这是一条底线。
4. 避坑与排查：五个真会卡住人的地方
4.1 服务注册成功但启动失败
现象：Get-Service nexus显示 Stopped，/start之后过几秒又回到 Stopped，事件查看器里有一条 1053 超时。
原因基本是两个：一是系统级JAVA_HOME没配，服务进程找不到 Java；二是nexus.vmoptions里-Xmx设得比物理内存还大，JVM 直接拒绝启动。
解决：先在服务属性里确认启动账户，再用该账户的环境跑一次java -version；把-Xmx降到物理内存的一半以内。日志在sonatype-work\nexus3\log\nexus.log，服务启动失败时这个文件里通常有一行明确的Error: Could not create the Java Virtual Machine。
4.2 deploy 报 401 或 403
现象：mvn deploy提示Return code is: 401, ReasonPhrase: Unauthorized，或者 403 Forbidden。
原因分三层看：401 是认证没过，通常是settings.xml里<server>的<id>和pom.xml里distributionManagement的<id>对不上，Maven 找不到对应的账号密码；403 是认证过了但没权限，多为角色少了add动作，或者目标仓库的Deployment policy是Disallow redeploy而你重复发布了同版本。
解决：先把两个 id 打印出来比对，注意大小写和空格；再确认该用户所属角色对目标仓库有add权限；最后看是不是改版本号就能过。
提示：密码写在 settings.xml 里时，建议用
mvn -ep生成加密串配合settings-security.xml，明文密码进版本库是另一个层面的坑。
4.3 快照拉不下来，日志里一堆 404
现象：依赖xxx-1.0.0-SNAPSHOT解析失败，Nexus 日志里能看到对快照元数据的 404。
原因通常是快照仓库没被加进 group，或者 group 里快照仓库排在 release 后面、而中间某一步的缓存把 404 记住了。Nexus 对「未找到」也会缓存一段时间，标错之后即使配置改对了，短时间内仍然返回 404。
解决：确认 group 成员包含快照仓库；执行Invalidate cache清掉负缓存；再在本地删掉~/.m2/repository下对应的快照目录重试。如果还不行，直接看该仓库的 Browse 页面里maven-metadata.xml是否存在，文件不在就是发布端压根没传上去。
4.4 磁盘被 blob 撑满
现象：某天突然所有上传返回 500，日志里No space left on device，一看sonatype-work目录几十个 G。
原因：Nexus 删除组件走的是软删除，blob store里的数据块不会立即回收，快照仓库每天覆盖几十次，几个月下来体积非常可观。
解决：建 Cleanup Policy 挂到快照仓库上，规则设成「保留最近 N 个版本、超过 X 天未下载的删掉」；再排一个Compact blob store的定时任务真正回收空间。手工删组件只能减小索引，不会减 blob，这一点很多人误解。
4.5 路径空格和网络盘引发的怪问题
现象：上传大文件时偶发失败，或者启动时报Could not resolve path。
原因：安装路径含空格、-Djava.io.tmpdir指到网络共享、karaf.data指到 UNC 路径，这三类都会导致文件锁或路径解析异常。Windows 上文件锁的语义和 Linux 差别不小，网络盘上尤其明显。
解决：安装目录和数据目录一律放本地盘、不含空格；tmpdir单独建一个本地目录并确保服务账户有写权限。这条没有技术含量，但出问题时的排查成本极高，属于提前规避比事后定位划算的典型。
5. 客户端接入：从 settings.xml 到离线构建
5.1 mirror 和 repository 的取舍
客户端接私服有两种写法：配mirror把某个仓库的请求整体重定向，或者配repository直接声明仓库地址。团队统一场景下我倾向 mirror，因为它在settings.xml里配置，不依赖每个项目的 pom，改一处全员生效。
<mirrorOf>的取值很关键：
| 值 | 效果 | 适用 |
|---|---|---|
* | 所有仓库请求都走私服 | 全内网团队，公共仓库不可直连 |
central | 只拦中央仓库 | 私服只是加速，其他仓库仍需直连 |
external:* | 拦所有外部仓库，本地仓库除外 | 兼顾灵活性的折中 |
用*的前提是 group 里已经把需要的远端仓库都代理进来了，否则会出现「某个依赖以前能下，接了私服反而下不了」。这是切私服时最高频的翻车点。
5.2 一份能直接抄的 settings.xml
<settings> <mirrors> <mirror> <!-- 名字随意，只用于本地识别 --> <id>nexus-local</id> <mirrorOf>*</mirrorOf> <url>http://192.168.1.20:8081/repository/maven-public/</url> </mirror> </mirrors> <servers> <!-- id 必须与 pom 中 distributionManagement 的 id 一致 --> <server> <id>nexus-releases</id> <username>deploy-user</username> <password>******</password> </server> <server> <id>nexus-snapshots</id> <username>deploy-user</username> <password>******</password> </server> </servers> <profiles> <profile> <id>nexus</id> <repositories> <repository> <id>nexus-public</id> <url>http://192.168.1.20:8081/repository/maven-public/</url> <releases><enabled>true</enabled></releases> <snapshots><enabled>true</enabled></snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>nexus-public</id> <url>http://192.168.1.20:8081/repository/maven-public/</url> </pluginRepository> </pluginRepositories> </profile> </profiles> <activeProfiles> <activeProfile>nexus</activeProfile> </activeProfiles> </settings>mirrors负责重定向，profiles负责声明可解析位置，两者都指向 group 地址。pluginRepositories单独列一份是因为插件解析走的通道和依赖不同，漏了它会出现「依赖能下、插件下不了」。activeProfiles里的 id 是 profile 的id，不是仓库的id，这两个名字经常被搞混。
对应 pom 侧的发布配置：
<distributionManagement> <repository> <id>nexus-releases</id> <url>http://192.168.1.20:8081/repository/maven-releases/</url> </repository> <snapshotRepository> <id>nexus-snapshots</id> <url>http://192.168.1.20:8081/repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement><id>与settings.xml的<server><id>严格一一对应，这是 401 的根源。<url>指向具体仓库而不是 group，group 是只读聚合，不能往里 deploy。
5.3 验证依赖到底走没走私服
改完配置不能凭感觉。三个验证手段，从轻到重：
# 1) 看解析日志里下载源 mvn -X dependency:resolve 2>&1 | grep -i "Downloading from" # 2) 清掉单个 artifact 的本地缓存再拉 rm -rf ~/.m2/repository/com/example/demo mvn dependency:get -Dartifact=com.example:demo:1.0.0 # 3) 构造离线场景验证 group 缓存是否真的生效 mvn -o clean package第一条命令输出里如果出现Downloading from nexus-local或 group 地址，说明 mirror 生效了。第二条用来排除「本地已经有缓存所以看着像通了」的假象。第三条-o是离线模式，它不访问任何远端，能成功说明所需构件都在本地仓库里——但它验证不了私服缓存，只能验证上一次解析是否完整，别把它当成私服联通性测试。
更直观的办法是去 Nexus 界面 Browse 对应 group，看构件是否出现在列表里，以及在 Search 里查maven-metadata.xml的时间戳。
5.4 Gradle 和老项目顺带接上
不是所有项目都用 Maven。Gradle 侧的写法要注意新版本对 HTTP 仓库的限制：
repositories { maven { url "http://192.168.1.20:8081/repository/maven-public/" allowInsecureProtocol = true // 走 HTTP 时必须显式开启 } } publishing { repositories { maven { url "http://192.168.1.20:8081/repository/maven-releases/" credentials { username project.findProperty("repoUser") password project.findProperty("repoPass") } } } }allowInsecureProtocol在较新的 Gradle 里是强制项，缺了会直接报仓库不安全而拒绝解析，报错信息不明显，容易误判成网络问题。凭据用project.findProperty从gradle.properties或命令行读，不要写死在build.gradle里。
前端项目的 npm 源也可以挂在同一个实例上，建一个 npm (proxy) 加一个 npm (hosted) 再聚合成 group，npm config set registry指过去就行，思路和 Maven 完全一致，只不过换了个仓库格式。
6. 备份、清理与升级：让这套东西能长期跑下去
搭起来只是开始，真正消耗精力的是三个月后的磁盘告警和半年后的一次迁移。先说备份：Nexus 的备份有两块，元数据和 blob 数据。界面上Tasks里建一个Admin - Export databases for backup的定时任务，它会周期性把数据导到sonatype-work\nexus3\backup下，生成带时间戳的目录。但导出任务只覆盖元数据，blob store 里的实际文件不在里面。
# 每日增量：导出任务落盘后，整体同步到备份盘 $src = "D:\nexus\sonatype-work\nexus3" $dst = "E:\backup\nexus\$(Get-Date -Format yyyyMMdd)" robocopy $src $dst /MIR /R:1 /W:1 /XD "$src\elasticsearch" /LOG+:"E:\backup\robocopy.log"/MIR是镜像模式，会删除目标端多余文件，配合日期目录使用才有意义，直接对同一个目标目录长期/MIR会把历史备份一起抹掉。/XD排除 elasticsearch 索引目录，这个目录可以在恢复后重建，没必要占备份空间。/R:1 /W:1把重试压到最低，避免备份任务在网络抖动时挂住几个小时。
清理这块，3.45 已经支持 Cleanup Policy，比早期手工删组件省事得多。策略写在Repository → Cleanup Policies里，规则组合一般是「保留最近 N 个快照版本」加「超过 X 天未被下载的删除」，然后把策略挂到快照仓库上。挂完之后不会立刻释放磁盘，还要配一个Compact blob store任务，它负责真正回收未被引用的数据块。这两个任务建议错开时间跑，别同时占用 IO。
注意：配了清理策略不等于立刻见效，第一次运行前建议先确认策略命中的组件数量，避免把还在用的基线版本清掉。
升级是最后一块。3.x 的升级路径是停服务、备份整个sonatype-work、解压新版本包到新目录、把旧etc下的定制配置（nexus-default.properties、nexus.vmoptions）拷过去、让新版本指到同一份数据目录。数据目录默认在同级，如果分开了，靠bin\nexus.vmoptions里的-Dkaraf.data指定。
# 升级前的三步：停、备、验版本 .\nexus.exe /stop nexus Copy-Item D:\nexus\sonatype-work D:\backup\pre-upgrade -Recurse Get-Content D:\nexus\sonatype-work\nexus3\version.txtversion.txt里记着当前数据格式版本，新版启动时会做一次不可逆的数据迁移，所以「先备份再启动」不是流程洁癖，是唯一的后悔药。迁移完成之后不能再用旧版程序去读这份数据，回滚只能靠备份恢复。
健康检查我习惯挂一个最简单的探针，比翻日志快得多：
curl -s -o /dev/null -w "%{http_code}" http://192.168.1.20:8081/service/rest/v1/status返回 200 表示服务在，返回 503 说明处于启动中或维护状态，两者都能被监控系统直接消费。
从那以后我每次动这个实例之前，都会强制走一遍「停服务、整目录拷贝、看 version.txt」这三步，哪怕只是改一行nexus.vmoptions。吃过一次亏：内存参数改错导致启动失败，数据目录里的索引没来得及刷盘，虽然最后靠重建索引恢复了，但那半天全组人都在等。希望帮到你。
本文还有配套的精品资源，点击获取
