简介这是Nexus 3.30.0.01的Windows 64位安装包面向需要搭建Maven私服的Java开发团队。它可解决公共仓库访问慢、依赖版本混乱、团队协作发布不便等常见问题适合具备一定构建经验的开发者快速部署。压缩包约212MB内含可执行程序与运行数据目录结构能够支撑本地仓库代理、仓库聚合和组件发布等核心功能。目前已有1791人学习/下载。借助该包可搭建企业级组件仓库环境其内置的权限控制、构件校验和搜索浏览能力让依赖管理更安全可控同时支持与Jenkins等CI/CD工具联动为自动化构建流程提供稳定基础。包内附带的目录结构也有助于理解Nexus的运行机制便于后续按需调整。1. nexus-3.30.0-01-win64.zip先搞清楚你下载的到底是个什么搜索“nexus”时你会先撞见一堆桌面美化工具和五花八门的官网入口但nexus-3.30.0-01-win64.zip是另一条赛道上的东西它是 Sonatype Nexus Repository Manager 3 的 3.30.0-01 版本、Windows 64 位发行压缩包。Nexus 是一个制品仓库管理器企业里用它统一存放 Maven、npm、NuGet、Docker 等构建产物对内提供下载对外代理中央仓库。你拿到这个 zip本质上拿到的是“一个需要跑在服务器上的服务端程序”不是双击就能用的桌面软件。它解决的问题很实际公共仓库慢、依赖被删、团队协作时只靠私有的 Git 存不了编译产物。这次我按自己搭过多次的方案把这个 zip 从解压到日常维护讲清楚参数和坑都放在对应的章节里。2. 装对再谈用Nexus 3.30 在 Windows 上的安装与首次登录2.1 环境选型3.30 为什么卡在 JDK 8Nexus 3.30.0-01 这个版本对运行时的要求相当明确需要 JDK 8。不是 11、不是 17就是 8。我见过有人拿新 JDK 去跑结果服务进程反复重启日志里报 UnsupportedClassVersionError最后绕一圈回来换 JDK 8 才正常。这是设计边界不是玄学3.30 是 3.x 中后期版本它的内核和 OrientDB 数据存储对 JDK 8 依赖很深官方在这个版本线上也是按 JDK 8 验证的。装 JDK 8 时别只看 java -version 的输出。Nexus 启动脚本会去找 JAVA_HOME如果系统里同时装了几个 JDK脚本优先用 JAVA_HOME 指向的那个。Windows 上常见的问题是 PATH 里有个老的 JRE而 JAVA_HOME 没配或者配错最后 Nexus 用的是 JRE 而不是 JDK某些管理功能就起不来。我的做法是单独给 Nexus 开一个系统环境变量 JAVA_HOME 指向 jdk8 的安装根目录不依赖 PATH 里的 Java。另外推荐把 zip 解压到一个不带空格的路径比如D:\nexus。这算是 Windows 上跑服务的老坑nexus.exe 在带空格路径下安装 Windows 服务时参数解析经常翻车启动脚本也会出现文件找不到。3.30 的安装包解压后是两个目录一个叫nexus-3.30.0-01程序本体另一个叫sonatype-work数据目录这两个目录最好保持同级后续升级和备份都方便。2.2 从解压 zip 到 8081 端口亮起来的命令序列先把最小启动路径跑通。3.30 在 Windows 上有两种启动方式直接跑 bin 下的脚本或者注册成 Windows 服务。首次验证建议用前台方式能直接看到日志排错最快。cd D:\nexus\nexus-3.30.0-01\bin nexus.bat run跑起来后日志会输出到sonatype-work\nexus3\log\nexus.log。看到类似Started Sonatype Nexus OSS 3.30.0-01的字样再开浏览器访问http://localhost:8081。日志文件里没有这句话说明服务还没准备好这时候别急着刷新页面回日志里看报错。前台验证没问题后再装 Windows 服务这样开机自启、后台运行都省心。用管理员权限打开命令提示符cd D:\nexus\nexus-3.30.0-01\bin nexus.exe install nexus.exe startnexus.exe install注册服务nexus.exe start启动服务。注意这里的 install 不改变目录内容只是把启动方式挂到 Windows 服务管理器上。如果 install 之后马上 start服务立刻报启动失败大多数情况下就是前面说的路径空格问题或者 JDK 版本不对去 Windows 事件查看器看日志。端口默认是 8081。这个端口不是写在 nexus.vmoptions 里的而是在nexus-3.30.0-01\etc\nexus-default.properties文件里。把application-port改成别的值重启后生效。生产上我通常不会留 8081换成 18081 之类的端口少一些扫描器盯上的概率。2.3 第一次登录admin.password 文件与初始密码管理首次访问时 Nexus 的管理员账号是 admin密码不在界面上在数据目录里。3.30 会在第一次启动时生成一个随机初始密码路径是D:\nexus\sonatype-work\nexus3\admin.password用文本编辑器打开这个文件里面就是登录密码。第一次登录后系统会引导你改密码改完这个文件会自动删除。如果文件删了而你还没记住改过的密码那就只能重置了。重置管理员密码在 3.30 上有点折腾停服删除sonatype-work\nexus3\db\security目录下的相关数据文件重启后会重新生成 admin.password。这算是一种后悔药但会丢掉所有现有用户和权限配置不是首选项。我一般会在部署当天就把密码改成强密码并把这个初始密码文件的内容单独存一份到内部密码库防止被覆盖。登录首页默认有向导建议跳过英文向导直接进设置原因很简单3.30 默认就在先把匿名访问关掉再建仓库体验更安全。匿名访问这块放第 4 章详细说这里先记住一点千万别在公网上用默认配置暴露 8081 端口3.30 的初始设置对安全并不友好。3. 把 Maven 和 npm 私服跑起来仓库类型与最小配置3.1 Hosted / Proxy / Group 三种仓库的分工Nexus 3 的仓库模型只有三种Hosted本地托管、Proxy远程代理、Group分组聚合。很多刚接触的人在这块绕弯子其实用场景一句话就能说清。Hosted 仓库存公司自己的构建产物相当于团队的私有盘Proxy 仓库用来缓存 Maven Central、npmjs 这些公共源团队里所有人下载依赖都走它第一次请求还是从公共源拉之后就走本地缓存外部网络波动对开发基本无感Group 仓库是前两者的入口把多个仓库聚合在一个 URL 后面客户端只配一个地址就行。登录后预置的仓库已经够用maven-central是 Proxymaven-releases和maven-snapshots是 Hostedmaven-public是 Group。npm 这边默认也有npmjsProxy、npm-hostedHosted、npm-groupGroup。如果团队里同时用 Maven 和 npm这两种仓库体系互不干扰同一个 Nexus 实例一起跑就行。创建仓库时有一组关键参数容易忽略Hosted 仓库的 Deployment policy。maven-releases 默认是Allow redeploymaven-snapshots 默认也允许。我的习惯是把 releases 仓库改成Disable redeploy因为已经发布的正式版本不允许覆盖能防止开发手滑把同一个版本号传了两份不同内容上去snapshots 仓库保持允许因为 SNAPSHOT 本来就是可变的。npm-hosted 那边也有类似策略叫Strict可以控制同名同版本的覆盖行为发布规范严格的团队可以打开。3.2 Maven 私服配置settings.xml 的 mirror 与 deploy 上传Maven 客户端接 Nexus 就两个配置文件settings.xml负责下载pom.xml负责上传。下载配置用 mirror 把几乎所有仓库地址都指向 maven-publicmirrors mirror idnexus/id mirrorOf*/mirrorOf urlhttp://localhost:8081/repository/maven-public//url /mirror /mirrorsmirrorOf写*表示所有仓库都走这个镜像适用于绝大多数场景。如果有的仓库故意不走私服可以用*,!central之类的排除写法但我建议除非有明确理由否则别这样弄团队里排查依赖来源时会头大。上传配置在项目 pom.xml 的 distributionManagement 里distributionManagement repository idnexus-releases/id urlhttp://localhost:8081/repository/maven-releases//url /repository snapshotRepository idnexus-snapshots/id urlhttp://localhost:8081/repository/maven-snapshots//url /snapshotRepository /distributionManagement这个 id 要和 settings.xml 里的 server id 一一对应否则上传时认证信息对不上servers server idnexus-releases/id usernamedeploy/username password你的密码/password /server server idnexus-snapshots/id usernamedeploy/username password你的密码/password /server /servers发布命令没什么特殊的就是mvn clean deploy。deploy 时会根据 pom.xml 里的 version 后缀判断走 release 还是 snapshot 仓库version 带-SNAPSHOT就去快照仓库不带就去正式仓库。常见的翻车是版本号不带 SNAPSHOT却往 maven-snapshots 传Nexus 直接 400 拒绝因为 snapshots 仓库不接受非快照版本反过来也一样。这条规则和 npm 那边类似细节写法不同但思路一致。3.3 npm 私服registry 切换、npm pack 与版本区分npm 接 Nexus 比 Maven 更轻量。把 registry 指到 npm-group 或者 npm-hosted 就行npm config set registry http://localhost:8081/repository/npm-group/下载依赖时用 npm-group它聚合了 npmjs 代理和 npm-hosted公共包和内部包都能装。但发布时方向不同npm publish 只能发到 hosted 仓库发到 group 会被拒绝。我见过不少人在这一步来回折腾界面报错也不直观最后发现 registry 配错了。发布前先确认一件事是“先打包还是先 npm init”。这个热词问的人很多答案是先npm init。因为决定“发布成哪个包的哪个版本”的是 package.json 的name和version字段而 npm pack 只是按 package.json 生成 tarball。如果跳过 npm init 直接 pack打出来的包可能没有 name 和 version或用的是默认值publish 时要么报错要么传到 Nexus 上变成无名残包清理起来很麻烦。最小发布流程mkdir my-lib cd my-lib npm init -y npm config set registry http://localhost:8081/repository/npm-hosted/ npm publish这里有个细节npm publish实际发布的是当前目录打出来的包内容与npm pack生成的 tarball 一致。想发发布前检查先npm pack --dry-run看一眼文件清单再决定会不会把 node_modules 或无关文件传上去。如果 package.json 里没写files字段npm 会把目录下几乎所有文件都打进去这是另一个常见翻车点。nexus 上区分同一组件不同版本完全依赖 package.json 的 version。同一个 npm-hosted 仓库里同名的包可以存在多个版本Nexus 默认允许共存拉取时按语义化版本规则解析。如果只想保留最新版本可以在仓库设置里打开Remove outdated packages之类的策略但这会导致旧版本不可用谨慎开启。私有包名这块最好统一规范内部发布的包一律用 scoped 形式比如company/logger。scoped 包默认是私有的配合 Nexus 的权限配置外部用户拉不到项目里引用时也不需要改 registry因为 npm-group 已经把 hosted 仓库聚合进去了。还有个配套参数是.npmrc里的认证信息发布到 hosted 仓库通常需要登录命令行执行npm login --registry http://localhost:8081/repository/npm-hosted/这个命令会在当前用户的.npmrc里写入一个 base64 编码的_auth字段。如果环境变量或 CI 里没法交互式登录可以手动拼接认证串echo -n deploy:你的密码 | base64然后把输出写到.npmrc的//localhost:8081/repository/npm-hosted/:_auth你的base64串。注意这里的 URL 路径不能写错npm 校验 auth 时会精确匹配 host 和 path 前缀。4. 资源边界与维护JVM 内存、blob 存储、备份和权限4.1 nexus.vmoptions 里的内存和端口参数Nexus 是一个跑在 JVM 里的服务内存参数写在nexus-3.30.0-01\bin\nexus.vmoptions里。我拆开看这个文件时重点只改两个值-Xms270m -Xmx270m默认堆内存只有 270MB个人测试够用团队规模上来后很容易出现 Full GC 频发、界面操作卡顿、npm 拉包超时。我一般按机器内存的四分之一到三分之一给比如 8GB 的开发服务器给-Xms2g -Xmx2g产线 16GB 机器给到 3g。注意 Xms 和 Xmx 最好设成一样的值避免 JVM 动态扩容带来的性能抖动这个在 Windows 服务器上尤其明显。文件末尾还会有一行-Dnexus.port相关的参数吗实际上 3.30 的端口不在 vmoptions 里而是前文提到的 nexus-default.properties。容易混的是-Djava.io.tmpdir和-XX:MaxDirectMemorySize。前者控制临时文件位置默认指到系统临时目录Nexus 上传大文件时会写临时文件如果系统临时目录在 C 盘且空间较小上传几个 G 的包会报磁盘空间不足。我在生产上会显式把它指到数据盘-Djava.io.tmpdirD:\nexus\tmp改完 vmoptions 后重启服务生效。这个文件是纯文本UTF-8 编码Windows 上用记事本另存时记得别存成带 BOM 的格式否则 JVM 启动参数解析会出毛病。4.2 blob 存储路径与最小可用备份方案3.30 的制品数据全部存在 blob 里路径是sonatype-work\nexus3\blobs。每个仓库对应 blobs 目录下的一个子目录里面是二进制块文件。数据库本身在sonatype-work\nexus3\db里面是 OrientDB 的库文件。两个目录合起来是 Nexus 的完整数据。备份这块容易踩坑直接在线复制 db 目录得到的备份大概率是坏的因为 OrientDB 写入时文件处于不一致状态。我常用的方案是“停服拷贝”虽然土但可靠。半夜执行net stop nexus xcopy D:\nexus\sonatype-work D:\backup\nexus-work-20250101 /E /I /H net start nexusWindow 的 xcopy 带上/E才拷贝空目录/I防止多目录确认提示/H连隐藏文件一起拷。恢复时把备份目录覆盖回去再启动服务即可。这个方案适合单体服务器好在 3.30 本来就是单机部署。如果想不停服可以用 Nexus 的 Cleanup 任务配合 blob 压缩但它不能替代备份。3.30 没有完整的在线全量备份 UI这是版本边界别指望有什么神奇的菜单。如果团队对可用性要求高我的建议是别在 Windows 单机上长期跑 Nexus把数据目录挂到网络存储上用快照来做更低频的备份。但要提醒OrientDB 对底层文件锁很敏感挂网络盘时如果锁机制不稳定Nexus 会直接启动失败。4.3 匿名访问收紧与只读账号3.30 默认允许匿名用户看仓库列表并下载制品这对内网开发是便利对外泄露是风险。收紧的第一步是进入 Administration Anonymous Access关闭匿名访问。关闭后Maven 和 npm 的下载也需要带认证信息CI 里配置会多一步但对安全来说是必要的。更细的做法是建一个只读账号给构建机用权限只配 Repositories 的 browse 和 read不给上传。这个账号在 Nexus 的用户管理里创建角色选nx-anonymous自带权限也可以但更可控的是自定义角色只勾选nx-repository-view-*-*-read和nx-repository-view-*-*-browse。这样即使构建机的密码泄露别人也只能下载不能篡改。npm 和 Maven 侧对只读账号的配置就是普通账号密码Maven 在 settings.xml 的 server 段里填npm 在.npmrc里填。只读账号还有一个好处Nexus UI 上的操作日志里可以区分谁在下依赖排障时能看出是哪个构建任务触发的大流量下载。5. Nexus 3.30 的运行维护避坑清单5.1 现象服务启动了但 8081 打不开这里的表现是 Windows 服务列表里状态是“正在运行”netstat -ano也看不到 8081 端口。原因通常有三层一是防火墙入站规则没放行本地 localhost 能开但局域网访问不行二是 Nexus 启动到一半卡住日志停在某个加载步骤界面自然是打不开的三是端口被别的进程占用了常见的是另一个 Nexus 实例或某个 Tomcat 用 8081。解决顺序先看sonatype-work\nexus3\log\nexus.log最后 30 行确认有没有报错。没有明显报错但一直等多半是 javaw.exe 进程还挂着把服务停了杀进程再启。防火墙层面我一般先临时放行一次netsh advfirewall firewall add rule nameNexus8081 dirin actionallow protocolTCP localport8081确认通了再写进策略里。端口占用则用netstat -ano | findstr 8081找出 PID到任务管理器里确认是不是自己的另一个 Java 进程。5.2 现象mvn deploy 报 401 或 400401 是认证没通过400 多数是仓库类型不匹配。401 我会先检查两个地方settings.xml 的 server id 是不是和 pom 的 distributionManagement. id 完全一致大小写都不差密码里如果有特殊字符在 XML 里要转义写成amp;。还有一个隐蔽原因Nexus 的用户到期或被禁用3.30 默认密码有效期策略是 60 天如果一开始用 admin 配置的密码超过 60 天没改账号会被锁定deploy 一直在 401UI 上却能登录。遇到这种症状先去用户管理里看账号状态。400 的典型是往 maven-snapshots 传非 SNAPSHOT 版本或者反过来。Nexus 的报错信息会写明 “Invalid version” 之类的提示对照 pom.xml 的 version 字段改后半段即可。5.3 现象npm publish 经常失败npm 在 Nexus 上最容易出的三类状况一是 registry 配成 group 地址publish 被拒绝二是没登录或.npmrc里_auth路径写错报 401三是包名不规范比如没有 scope 且和公共包重名Nexus 不会校验公共包重名但后面下载时容易混淆。解决时先把 registry 切到 npm-hosted 地址执行npm whoami验证认证是否生效然后确认 package.json 的 name 带 scope 前缀。发布前先用npm pack --dry-run看清楚包里有什么再执行npm publish。有的团队在 CI 上会遇到.npmrc写入了但工作目录里节点的 npm 版本对_auth格式解析不一致的问题统一 Node 版本可以根治。5.4 现象升级后数据目录启动失败或新版本找不到旧数据Nexus 3.30 用的存储引擎是 OrientDB而 4.x 系列换成了 H2这不是小版本升级能自动平滑的。如果你手里这个 3.30 是要往上升级的千万别直接用 4.x 的程序指向 3.30 的 sonatype-work启动时大概率直接报 migration 错误。官方提供的是升级路径但要在目标版本里执行迁移。这里我建议别在生产上一键升级先复制一个副本目录用副本跑一次升级流程确认数据完整后再切正式。Windows 环境下尤其先确认磁盘剩余空间至少是数据目录的两倍迁移过程会有大量临时文件。顺带说一个容易出事的习惯把自己旧的 maven 仓库目录直接拖进 blob 目录想导入那是行不通的。Nexus 只会认它自己的 blob 格式历史版本的依赖要么通过代理仓库重新拉要么用 mvn deploy 逐个传上去没有“放进去就能用”的捷径。6. 冷门但能救命的两个技巧6.1 用 Cleanup 策略自动清理 snapshot 老版本3.30 的 UI 里可以配置 Cleanup Policy很多团队根本不用结果 snapshot 仓库越来越大blob 目录膨胀到几十 GB。我一般在 Administration → Cleanup Policies 里建两条策略。一条针对 maven-snapshots按Last downloaded超过 30 天且Release version是 SNAPSHOT 来清理另一条针对 npm-hosted按发布年龄保留最近 20 个版本。策略配好后一定要在仓库设置的 Cleanup Policy 标签页里勾上否则策略建了不生效。这个操作比手动删制品安全得多Nexus 会同时清理对应的 blob 块。6.2 脚本化批量上传用 REST API 省掉手工点击如果要从旧仓库批量导包不要在 UI 里一个个传用 Nexus 的 REST API 配合 curl 写循环。上传到 Maven 仓库的用法是curl -u admin:密码 \ -X POST \ -H Content-Type: application/octet-stream \ --data-binary my-lib-1.0.jar \ http://localhost:8081/service/rest/v1/components?repositorymaven-releases这个接口上传的制品没有 Maven 坐标Nexus 会把文件名当坐标解析。所以批量脚本里要保证文件名符合groupId/artifactId/version/的目录结构或者逐个传坐标参数。更省事的做法是针对 Maven 的mvn deploy:deploy-file写循环把坐标信息作为命令行参数一个个传但慢一些。我自己处理过一批几百个历史 jar最后是写了一个 Python 脚本用 REST API 逐个传并打印状态码失败的重试三次并记录到日志。这类脚本不复杂但救急时非常管用。这两招配合起来3.30 的日常维护基本就够用了。说到底这个 zip 解压出来的东西不复杂复杂的是想清楚怎么用、怎么守、怎么备。我自己的教训是拿到一个新环境先别急着开匿名访问和改一堆花哨配置先把 admin 密码改了、备份路径确认了再动仓库。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/28 18:41:18 · 阅读 1.2k Nexus 3.30 Windows部署指南：构建Maven与npm私服仓库
简介这是Nexus 3.30.0.01的Windows 64位安装包面向需要搭建Maven私服的Java开发团队。它可解决公共仓库访问慢、依赖版本混乱、团队协作发布不便等常见问题适合具备一定构建经验的开发者快速部署。压缩包约212MB内含可执行程序与运行数据目录结构能够支撑本地仓库代理、仓库聚合和组件发布等核心功能。目前已有1791人学习/下载。借助该包可搭建企业级组件仓库环境其内置的权限控制、构件校验和搜索浏览能力让依赖管理更安全可控同时支持与Jenkins等CI/CD工具联动为自动化构建流程提供稳定基础。包内附带的目录结构也有助于理解Nexus的运行机制便于后续按需调整。1. nexus-3.30.0-01-win64.zip先搞清楚你下载的到底是个什么搜索“nexus”时你会先撞见一堆桌面美化工具和五花八门的官网入口但nexus-3.30.0-01-win64.zip是另一条赛道上的东西它是 Sonatype Nexus Repository Manager 3 的 3.30.0-01 版本、Windows 64 位发行压缩包。Nexus 是一个制品仓库管理器企业里用它统一存放 Maven、npm、NuGet、Docker 等构建产物对内提供下载对外代理中央仓库。你拿到这个 zip本质上拿到的是“一个需要跑在服务器上的服务端程序”不是双击就能用的桌面软件。它解决的问题很实际公共仓库慢、依赖被删、团队协作时只靠私有的 Git 存不了编译产物。这次我按自己搭过多次的方案把这个 zip 从解压到日常维护讲清楚参数和坑都放在对应的章节里。2. 装对再谈用Nexus 3.30 在 Windows 上的安装与首次登录2.1 环境选型3.30 为什么卡在 JDK 8Nexus 3.30.0-01 这个版本对运行时的要求相当明确需要 JDK 8。不是 11、不是 17就是 8。我见过有人拿新 JDK 去跑结果服务进程反复重启日志里报 UnsupportedClassVersionError最后绕一圈回来换 JDK 8 才正常。这是设计边界不是玄学3.30 是 3.x 中后期版本它的内核和 OrientDB 数据存储对 JDK 8 依赖很深官方在这个版本线上也是按 JDK 8 验证的。装 JDK 8 时别只看 java -version 的输出。Nexus 启动脚本会去找 JAVA_HOME如果系统里同时装了几个 JDK脚本优先用 JAVA_HOME 指向的那个。Windows 上常见的问题是 PATH 里有个老的 JRE而 JAVA_HOME 没配或者配错最后 Nexus 用的是 JRE 而不是 JDK某些管理功能就起不来。我的做法是单独给 Nexus 开一个系统环境变量 JAVA_HOME 指向 jdk8 的安装根目录不依赖 PATH 里的 Java。另外推荐把 zip 解压到一个不带空格的路径比如D:\nexus。这算是 Windows 上跑服务的老坑nexus.exe 在带空格路径下安装 Windows 服务时参数解析经常翻车启动脚本也会出现文件找不到。3.30 的安装包解压后是两个目录一个叫nexus-3.30.0-01程序本体另一个叫sonatype-work数据目录这两个目录最好保持同级后续升级和备份都方便。2.2 从解压 zip 到 8081 端口亮起来的命令序列先把最小启动路径跑通。3.30 在 Windows 上有两种启动方式直接跑 bin 下的脚本或者注册成 Windows 服务。首次验证建议用前台方式能直接看到日志排错最快。cd D:\nexus\nexus-3.30.0-01\bin nexus.bat run跑起来后日志会输出到sonatype-work\nexus3\log\nexus.log。看到类似Started Sonatype Nexus OSS 3.30.0-01的字样再开浏览器访问http://localhost:8081。日志文件里没有这句话说明服务还没准备好这时候别急着刷新页面回日志里看报错。前台验证没问题后再装 Windows 服务这样开机自启、后台运行都省心。用管理员权限打开命令提示符cd D:\nexus\nexus-3.30.0-01\bin nexus.exe install nexus.exe startnexus.exe install注册服务nexus.exe start启动服务。注意这里的 install 不改变目录内容只是把启动方式挂到 Windows 服务管理器上。如果 install 之后马上 start服务立刻报启动失败大多数情况下就是前面说的路径空格问题或者 JDK 版本不对去 Windows 事件查看器看日志。端口默认是 8081。这个端口不是写在 nexus.vmoptions 里的而是在nexus-3.30.0-01\etc\nexus-default.properties文件里。把application-port改成别的值重启后生效。生产上我通常不会留 8081换成 18081 之类的端口少一些扫描器盯上的概率。2.3 第一次登录admin.password 文件与初始密码管理首次访问时 Nexus 的管理员账号是 admin密码不在界面上在数据目录里。3.30 会在第一次启动时生成一个随机初始密码路径是D:\nexus\sonatype-work\nexus3\admin.password用文本编辑器打开这个文件里面就是登录密码。第一次登录后系统会引导你改密码改完这个文件会自动删除。如果文件删了而你还没记住改过的密码那就只能重置了。重置管理员密码在 3.30 上有点折腾停服删除sonatype-work\nexus3\db\security目录下的相关数据文件重启后会重新生成 admin.password。这算是一种后悔药但会丢掉所有现有用户和权限配置不是首选项。我一般会在部署当天就把密码改成强密码并把这个初始密码文件的内容单独存一份到内部密码库防止被覆盖。登录首页默认有向导建议跳过英文向导直接进设置原因很简单3.30 默认就在先把匿名访问关掉再建仓库体验更安全。匿名访问这块放第 4 章详细说这里先记住一点千万别在公网上用默认配置暴露 8081 端口3.30 的初始设置对安全并不友好。3. 把 Maven 和 npm 私服跑起来仓库类型与最小配置3.1 Hosted / Proxy / Group 三种仓库的分工Nexus 3 的仓库模型只有三种Hosted本地托管、Proxy远程代理、Group分组聚合。很多刚接触的人在这块绕弯子其实用场景一句话就能说清。Hosted 仓库存公司自己的构建产物相当于团队的私有盘Proxy 仓库用来缓存 Maven Central、npmjs 这些公共源团队里所有人下载依赖都走它第一次请求还是从公共源拉之后就走本地缓存外部网络波动对开发基本无感Group 仓库是前两者的入口把多个仓库聚合在一个 URL 后面客户端只配一个地址就行。登录后预置的仓库已经够用maven-central是 Proxymaven-releases和maven-snapshots是 Hostedmaven-public是 Group。npm 这边默认也有npmjsProxy、npm-hostedHosted、npm-groupGroup。如果团队里同时用 Maven 和 npm这两种仓库体系互不干扰同一个 Nexus 实例一起跑就行。创建仓库时有一组关键参数容易忽略Hosted 仓库的 Deployment policy。maven-releases 默认是Allow redeploymaven-snapshots 默认也允许。我的习惯是把 releases 仓库改成Disable redeploy因为已经发布的正式版本不允许覆盖能防止开发手滑把同一个版本号传了两份不同内容上去snapshots 仓库保持允许因为 SNAPSHOT 本来就是可变的。npm-hosted 那边也有类似策略叫Strict可以控制同名同版本的覆盖行为发布规范严格的团队可以打开。3.2 Maven 私服配置settings.xml 的 mirror 与 deploy 上传Maven 客户端接 Nexus 就两个配置文件settings.xml负责下载pom.xml负责上传。下载配置用 mirror 把几乎所有仓库地址都指向 maven-publicmirrors mirror idnexus/id mirrorOf*/mirrorOf urlhttp://localhost:8081/repository/maven-public//url /mirror /mirrorsmirrorOf写*表示所有仓库都走这个镜像适用于绝大多数场景。如果有的仓库故意不走私服可以用*,!central之类的排除写法但我建议除非有明确理由否则别这样弄团队里排查依赖来源时会头大。上传配置在项目 pom.xml 的 distributionManagement 里distributionManagement repository idnexus-releases/id urlhttp://localhost:8081/repository/maven-releases//url /repository snapshotRepository idnexus-snapshots/id urlhttp://localhost:8081/repository/maven-snapshots//url /snapshotRepository /distributionManagement这个 id 要和 settings.xml 里的 server id 一一对应否则上传时认证信息对不上servers server idnexus-releases/id usernamedeploy/username password你的密码/password /server server idnexus-snapshots/id usernamedeploy/username password你的密码/password /server /servers发布命令没什么特殊的就是mvn clean deploy。deploy 时会根据 pom.xml 里的 version 后缀判断走 release 还是 snapshot 仓库version 带-SNAPSHOT就去快照仓库不带就去正式仓库。常见的翻车是版本号不带 SNAPSHOT却往 maven-snapshots 传Nexus 直接 400 拒绝因为 snapshots 仓库不接受非快照版本反过来也一样。这条规则和 npm 那边类似细节写法不同但思路一致。3.3 npm 私服registry 切换、npm pack 与版本区分npm 接 Nexus 比 Maven 更轻量。把 registry 指到 npm-group 或者 npm-hosted 就行npm config set registry http://localhost:8081/repository/npm-group/下载依赖时用 npm-group它聚合了 npmjs 代理和 npm-hosted公共包和内部包都能装。但发布时方向不同npm publish 只能发到 hosted 仓库发到 group 会被拒绝。我见过不少人在这一步来回折腾界面报错也不直观最后发现 registry 配错了。发布前先确认一件事是“先打包还是先 npm init”。这个热词问的人很多答案是先npm init。因为决定“发布成哪个包的哪个版本”的是 package.json 的name和version字段而 npm pack 只是按 package.json 生成 tarball。如果跳过 npm init 直接 pack打出来的包可能没有 name 和 version或用的是默认值publish 时要么报错要么传到 Nexus 上变成无名残包清理起来很麻烦。最小发布流程mkdir my-lib cd my-lib npm init -y npm config set registry http://localhost:8081/repository/npm-hosted/ npm publish这里有个细节npm publish实际发布的是当前目录打出来的包内容与npm pack生成的 tarball 一致。想发发布前检查先npm pack --dry-run看一眼文件清单再决定会不会把 node_modules 或无关文件传上去。如果 package.json 里没写files字段npm 会把目录下几乎所有文件都打进去这是另一个常见翻车点。nexus 上区分同一组件不同版本完全依赖 package.json 的 version。同一个 npm-hosted 仓库里同名的包可以存在多个版本Nexus 默认允许共存拉取时按语义化版本规则解析。如果只想保留最新版本可以在仓库设置里打开Remove outdated packages之类的策略但这会导致旧版本不可用谨慎开启。私有包名这块最好统一规范内部发布的包一律用 scoped 形式比如company/logger。scoped 包默认是私有的配合 Nexus 的权限配置外部用户拉不到项目里引用时也不需要改 registry因为 npm-group 已经把 hosted 仓库聚合进去了。还有个配套参数是.npmrc里的认证信息发布到 hosted 仓库通常需要登录命令行执行npm login --registry http://localhost:8081/repository/npm-hosted/这个命令会在当前用户的.npmrc里写入一个 base64 编码的_auth字段。如果环境变量或 CI 里没法交互式登录可以手动拼接认证串echo -n deploy:你的密码 | base64然后把输出写到.npmrc的//localhost:8081/repository/npm-hosted/:_auth你的base64串。注意这里的 URL 路径不能写错npm 校验 auth 时会精确匹配 host 和 path 前缀。4. 资源边界与维护JVM 内存、blob 存储、备份和权限4.1 nexus.vmoptions 里的内存和端口参数Nexus 是一个跑在 JVM 里的服务内存参数写在nexus-3.30.0-01\bin\nexus.vmoptions里。我拆开看这个文件时重点只改两个值-Xms270m -Xmx270m默认堆内存只有 270MB个人测试够用团队规模上来后很容易出现 Full GC 频发、界面操作卡顿、npm 拉包超时。我一般按机器内存的四分之一到三分之一给比如 8GB 的开发服务器给-Xms2g -Xmx2g产线 16GB 机器给到 3g。注意 Xms 和 Xmx 最好设成一样的值避免 JVM 动态扩容带来的性能抖动这个在 Windows 服务器上尤其明显。文件末尾还会有一行-Dnexus.port相关的参数吗实际上 3.30 的端口不在 vmoptions 里而是前文提到的 nexus-default.properties。容易混的是-Djava.io.tmpdir和-XX:MaxDirectMemorySize。前者控制临时文件位置默认指到系统临时目录Nexus 上传大文件时会写临时文件如果系统临时目录在 C 盘且空间较小上传几个 G 的包会报磁盘空间不足。我在生产上会显式把它指到数据盘-Djava.io.tmpdirD:\nexus\tmp改完 vmoptions 后重启服务生效。这个文件是纯文本UTF-8 编码Windows 上用记事本另存时记得别存成带 BOM 的格式否则 JVM 启动参数解析会出毛病。4.2 blob 存储路径与最小可用备份方案3.30 的制品数据全部存在 blob 里路径是sonatype-work\nexus3\blobs。每个仓库对应 blobs 目录下的一个子目录里面是二进制块文件。数据库本身在sonatype-work\nexus3\db里面是 OrientDB 的库文件。两个目录合起来是 Nexus 的完整数据。备份这块容易踩坑直接在线复制 db 目录得到的备份大概率是坏的因为 OrientDB 写入时文件处于不一致状态。我常用的方案是“停服拷贝”虽然土但可靠。半夜执行net stop nexus xcopy D:\nexus\sonatype-work D:\backup\nexus-work-20250101 /E /I /H net start nexusWindow 的 xcopy 带上/E才拷贝空目录/I防止多目录确认提示/H连隐藏文件一起拷。恢复时把备份目录覆盖回去再启动服务即可。这个方案适合单体服务器好在 3.30 本来就是单机部署。如果想不停服可以用 Nexus 的 Cleanup 任务配合 blob 压缩但它不能替代备份。3.30 没有完整的在线全量备份 UI这是版本边界别指望有什么神奇的菜单。如果团队对可用性要求高我的建议是别在 Windows 单机上长期跑 Nexus把数据目录挂到网络存储上用快照来做更低频的备份。但要提醒OrientDB 对底层文件锁很敏感挂网络盘时如果锁机制不稳定Nexus 会直接启动失败。4.3 匿名访问收紧与只读账号3.30 默认允许匿名用户看仓库列表并下载制品这对内网开发是便利对外泄露是风险。收紧的第一步是进入 Administration Anonymous Access关闭匿名访问。关闭后Maven 和 npm 的下载也需要带认证信息CI 里配置会多一步但对安全来说是必要的。更细的做法是建一个只读账号给构建机用权限只配 Repositories 的 browse 和 read不给上传。这个账号在 Nexus 的用户管理里创建角色选nx-anonymous自带权限也可以但更可控的是自定义角色只勾选nx-repository-view-*-*-read和nx-repository-view-*-*-browse。这样即使构建机的密码泄露别人也只能下载不能篡改。npm 和 Maven 侧对只读账号的配置就是普通账号密码Maven 在 settings.xml 的 server 段里填npm 在.npmrc里填。只读账号还有一个好处Nexus UI 上的操作日志里可以区分谁在下依赖排障时能看出是哪个构建任务触发的大流量下载。5. Nexus 3.30 的运行维护避坑清单5.1 现象服务启动了但 8081 打不开这里的表现是 Windows 服务列表里状态是“正在运行”netstat -ano也看不到 8081 端口。原因通常有三层一是防火墙入站规则没放行本地 localhost 能开但局域网访问不行二是 Nexus 启动到一半卡住日志停在某个加载步骤界面自然是打不开的三是端口被别的进程占用了常见的是另一个 Nexus 实例或某个 Tomcat 用 8081。解决顺序先看sonatype-work\nexus3\log\nexus.log最后 30 行确认有没有报错。没有明显报错但一直等多半是 javaw.exe 进程还挂着把服务停了杀进程再启。防火墙层面我一般先临时放行一次netsh advfirewall firewall add rule nameNexus8081 dirin actionallow protocolTCP localport8081确认通了再写进策略里。端口占用则用netstat -ano | findstr 8081找出 PID到任务管理器里确认是不是自己的另一个 Java 进程。5.2 现象mvn deploy 报 401 或 400401 是认证没通过400 多数是仓库类型不匹配。401 我会先检查两个地方settings.xml 的 server id 是不是和 pom 的 distributionManagement. id 完全一致大小写都不差密码里如果有特殊字符在 XML 里要转义写成amp;。还有一个隐蔽原因Nexus 的用户到期或被禁用3.30 默认密码有效期策略是 60 天如果一开始用 admin 配置的密码超过 60 天没改账号会被锁定deploy 一直在 401UI 上却能登录。遇到这种症状先去用户管理里看账号状态。400 的典型是往 maven-snapshots 传非 SNAPSHOT 版本或者反过来。Nexus 的报错信息会写明 “Invalid version” 之类的提示对照 pom.xml 的 version 字段改后半段即可。5.3 现象npm publish 经常失败npm 在 Nexus 上最容易出的三类状况一是 registry 配成 group 地址publish 被拒绝二是没登录或.npmrc里_auth路径写错报 401三是包名不规范比如没有 scope 且和公共包重名Nexus 不会校验公共包重名但后面下载时容易混淆。解决时先把 registry 切到 npm-hosted 地址执行npm whoami验证认证是否生效然后确认 package.json 的 name 带 scope 前缀。发布前先用npm pack --dry-run看清楚包里有什么再执行npm publish。有的团队在 CI 上会遇到.npmrc写入了但工作目录里节点的 npm 版本对_auth格式解析不一致的问题统一 Node 版本可以根治。5.4 现象升级后数据目录启动失败或新版本找不到旧数据Nexus 3.30 用的存储引擎是 OrientDB而 4.x 系列换成了 H2这不是小版本升级能自动平滑的。如果你手里这个 3.30 是要往上升级的千万别直接用 4.x 的程序指向 3.30 的 sonatype-work启动时大概率直接报 migration 错误。官方提供的是升级路径但要在目标版本里执行迁移。这里我建议别在生产上一键升级先复制一个副本目录用副本跑一次升级流程确认数据完整后再切正式。Windows 环境下尤其先确认磁盘剩余空间至少是数据目录的两倍迁移过程会有大量临时文件。顺带说一个容易出事的习惯把自己旧的 maven 仓库目录直接拖进 blob 目录想导入那是行不通的。Nexus 只会认它自己的 blob 格式历史版本的依赖要么通过代理仓库重新拉要么用 mvn deploy 逐个传上去没有“放进去就能用”的捷径。6. 冷门但能救命的两个技巧6.1 用 Cleanup 策略自动清理 snapshot 老版本3.30 的 UI 里可以配置 Cleanup Policy很多团队根本不用结果 snapshot 仓库越来越大blob 目录膨胀到几十 GB。我一般在 Administration → Cleanup Policies 里建两条策略。一条针对 maven-snapshots按Last downloaded超过 30 天且Release version是 SNAPSHOT 来清理另一条针对 npm-hosted按发布年龄保留最近 20 个版本。策略配好后一定要在仓库设置的 Cleanup Policy 标签页里勾上否则策略建了不生效。这个操作比手动删制品安全得多Nexus 会同时清理对应的 blob 块。6.2 脚本化批量上传用 REST API 省掉手工点击如果要从旧仓库批量导包不要在 UI 里一个个传用 Nexus 的 REST API 配合 curl 写循环。上传到 Maven 仓库的用法是curl -u admin:密码 \ -X POST \ -H Content-Type: application/octet-stream \ --data-binary my-lib-1.0.jar \ http://localhost:8081/service/rest/v1/components?repositorymaven-releases这个接口上传的制品没有 Maven 坐标Nexus 会把文件名当坐标解析。所以批量脚本里要保证文件名符合groupId/artifactId/version/的目录结构或者逐个传坐标参数。更省事的做法是针对 Maven 的mvn deploy:deploy-file写循环把坐标信息作为命令行参数一个个传但慢一些。我自己处理过一批几百个历史 jar最后是写了一个 Python 脚本用 REST API 逐个传并打印状态码失败的重试三次并记录到日志。这类脚本不复杂但救急时非常管用。这两招配合起来3.30 的日常维护基本就够用了。说到底这个 zip 解压出来的东西不复杂复杂的是想清楚怎么用、怎么守、怎么备。我自己的教训是拿到一个新环境先别急着开匿名访问和改一堆花哨配置先把 admin 密码改了、备份路径确认了再动仓库。希望帮到你。本文还有配套的精品资源点击获取