简介nexus-3.24.0-02-unix.tar.gz 是 Sonatype 公司 Nexus Repository Manager 3.24.0-02 版本的 Unix/Linux 安装包面向 Java 开发者、Maven/Gradle 用户以及需要统一管理 NPM、NuGet 等制品的团队用于搭建私有软件仓库与代理仓库解决依赖下载缓慢、制品分散与权限管理问题。资源包约 149.69MB解压后主要包含 nexus-3.24.0-02 主程序目录含可执行文件、配置与库和 sonatype-work 工作目录用于存放制品、索引、日志与数据库目录结构清晰便于快速部署与升级时保留数据压缩包内具体文件总数未单独统计。当前已有 212 人浏览学习。通过该包部署 Nexus 后可配置 Maven 中央仓库代理加速依赖获取将 Nexus 设为团队 NPM 默认 registry 实现包缓存和私有托管并在 Web 控制台中创建代理仓库、存储库组与细粒度权限策略。无论是初学者搭建第一个制品仓库还是团队希望构建内网统一软件源这份原始官方安装包都能带来可靠的起点。1. Nexus 3.24.0-02一个 tar.gz 把 Maven 和 NPM 私服跑起来第一次搭私服很多人会纠结 Sonatype Nexus 还是 Artifactory我的答案很简单先看预算。Artifactory 的企业功能确实全但团队只是想把手里的 Maven 和 NPM 依赖在内网收拢起来那 Nexus OSS 这款免费开源的仓库管理器完全够用。这份 nexus-3.24.0-02-unix.tar.gz 是 3.x 系列里我用得最顺手的一个版本tar.gz 解压即用内置 Maven、NPM、Docker、Raw 等格式支持默认端口 8081单机十分钟内能跑起来。下面我照着生产环境的部署流程把安装、Maven 仓库、NPM 仓库以及后来踩过的五个坑完整写出来。新手照着命令敲两小时能出活老手可以直接跳到第 3 章看参数表。2. 安装与首次启动从解压到替 admin 改密码2.1 解压与目录结构nexus 和 sonatype-work 谁是谁tar.gz 解压后会在目标目录下生成两个平级目录先用tree -L 1 /opt把结构认清楚/opt/ ├── nexus-3.24.0-02/ │ ├── bin/ │ │ └── nexus │ ├── etc/ │ │ ├── nexus.properties │ │ └── jetty/ │ └── lib/ └── sonatype-work/ └── nexus3/ ├── admin.password ├── log/ └── db/nexus-3.24.0-02是程序目录升级、打补丁、覆盖安装都动这里sonatype-work是数据目录仓库配置、组件文件、数据库都落在里面。我踩过的第一个坑就是把两者混在一起看程序目录坏了可以重新解压数据目录没了仓库里的依赖全得重新拉一遍。生产环境我会把sonatype-work单独挂到容量大的数据盘或者用软链接指过去而不是让它跟着/opt走。解压时注意不要用 root 跑后续的启动。Nexus 官方不建议 root 运行我习惯先建一个专用系统用户再解压、授权、启动。这样即使管理界面有安全漏洞shell 权限也局限在这个用户内。2.2 JVM 配置nexus.vmoptions 里我改了三个参数启动前打开bin/nexus.vmoptions里面是 JVM 参数。这个文件的核心是三行内存配置-Xms1024m -Xmx1024m -XX:MaxDirectMemorySize2g内存给多少没有固定的答案我给一个判断标准机器内存小于等于 4G 时Xms 和 Xmx 都压到 1024m内存大于 8G 时给到 3g 到 4g。我一般把 Xms 和 Xmx 设成同一个值避免运行时动态扩容触发 GC 抖动。MaxDirectMemorySize 影响 NIO 和 Jetty 的缓冲NPM 包并发下载时容易吃满设到 2g 起步比较稳妥。3.24.0-02 这个版本要求 JDK 8不要用 JDK 9 以上的版本去跑。常见做法是用系统自带的 JDK 8如果服务器上默认 java 版本不对在bin/nexus脚本顶部手动指定INSTALL4J_JAVA_HOME指向 JDK 8 的路径。这个参数比改 PATH 可靠Nexus 的启动工具会优先读它。2.3 启动、看日志、改密码十分钟跑通用专用用户启动命令顺序我总结成一套避免权限混乱useradd -r -m -s /bin/bash nexus tar -zxvf nexus-3.24.0-02-unix.tar.gz -C /opt chown -R nexus:nexus /opt/nexus-3.24.0-02 su - nexus -c /opt/nexus-3.24.0-02/bin/nexus start sleep 20 tail -n 30 /opt/sonatype-work/nexus3/log/nexus.log启动脚本是通过su切换到 nexus 用户执行的这样数据目录会由 nexus 用户自动创建不需要提前建目录。sleep 20是个缓冲让服务把嵌入式数据库初始化完再去看日志。日志里出现Started Sonatype Nexus OSS就说明启动成功。如果没看到用前台模式跑一遍看完整报错su - nexus -c /opt/nexus-3.24.0-02/bin/nexus run这样错误信息直接刷在终端里比翻日志更直观。首次启动后浏览器访问http://服务器IP:8081点右上角 Sign in用户名是admin密码在第一次启动时自动生成cat /opt/sonatype-work/nexus3/admin.password登录后系统会强制改密。改完密这个文件就会失效不用手动删。如果服务器开了防火墙记得放行 8081 端口firewall-cmd --add-port8081/tcp --permanent firewall-cmd --reload提示不要跳过改密这一步。管理员密码是空的私服在内网里等于请人进来乱传包。3. Maven 仓库实战proxy、hosted、group 三件套的配置与顺序3.1 三种仓库角色怎么配proxy 拉远程hosted 存私有group 聚合Nexus 的 Maven 仓库本质是三种角色的组合。proxy 是远程代理它从中央仓库或阿里云镜像拉依赖到本地缓存团队里任何一个人请求过的 jar第二个人再请求就走内网hosted 是私有宿主仓库自己写的公共组件 deploy 到这里只对自己人开放group 是聚合入口把 proxy 和 hosted 合并成一个地址客户端只配这一个 URL不感知后面有几个仓库。为什么需要 group 而不是让客户端配置多个源因为 Maven 在处理多个远程仓库时同一个构件的查找顺序不受你控制容易出现这边缓存了旧版本、那边有新版但没查到的情况。group 可以在配置里严格声明查找顺序私有仓库排在前中央代理排在后命中第一个就停。这个顺序是后面排错的重要基础。Nexus 3.24 安装完自带一组默认 Maven 仓库maven-central、maven-releases、maven-snapshots、maven-public。官方把最标准的组合已经配好了。我不建议直接复用原因是默认仓库都落在同一个 blob store 里以后想单独迁移 releases 数据会很麻烦。更清晰的做法是在界面上先建 blob store再一格格建自己的仓库。3.2 建仓库参数表URL、Blob Store、Deployment Policy 怎么填先到 Settings 的 Blob Stores 里创建三个 blob storemaven-blob、releases-blob、snapshots-blob分别对应代理缓存、正式包、快照包。然后再到 Repositories 创建仓库核心参数如下参数我的取值说明Namemaven-central仓库名同时影响访问路径Remote Storagehttps://repo1.maven.org/maven2/中央仓库国内网络建议换成阿里云镜像Auto Blocktrue远程连续失败时自动熔断不拖累本地Blob Storemaven-blob代理缓存放这里独立磁盘管理Deployment PolicyDisable redeploy仅 hosted 仓库有正式包不允许覆盖Version PolicyReleasehosted 仓库只收 Release 包Layout PolicyMaven 2不是 Maven 1这个不能选错hosted 仓库要建两个一个给正式版maven-releases一个给快照版maven-snapshots。关键差异在 Deployment Policyreleases 仓库选 Disable redeploy同名同版本传第二次直接拒收保证线上构件的不可变snapshots 仓库选 Allow redeploy开发阶段的快照版本允许覆盖重新发布。如果两个都选成 Disable redeploy持续集成里每次快照构建都会 400。group 仓库的成员顺序是关键。在maven-public的 Members 列表里把 hosted 仓库拖到 proxy 上面顺序仓库名类型作用1maven-releaseshosted私有正式包优先命中2maven-snapshotshosted私有快照包优先命中3maven-centralproxy中央仓库兜底这个顺序不是随便排的。Nexus 的 group 按列表从上到下逐个查如果 proxy 排在前面私有包名正好和中央仓库某个同名构件冲突就会被远程的旧版本先截胡这个问题排查起来非常隐蔽。3.3 本地配置settings.xml 与 pom.xml 的对应关系Maven 客户端的约 30 分钟配置核心是settings.xml里的 mirror 和 server。mirror 把所有对外的 Maven 依赖请求全部拦截转到 Nexussettings servers server idmaven-releases/id usernameadmin/username password{你的Nexus密码}/password /server server idmaven-snapshots/id usernameadmin/username password{你的Nexus密码}/password /server /servers mirrors mirror idnexus/id mirrorOf*/mirrorOf urlhttp://192.168.1.10:8081/repository/maven-public//url /mirror /mirrors /settingsmirrorOf*表示所有依赖请求都撞到 Nexus 一个入口上配置最简单适合纯内网环境。如果项目里还有其他独立仓库必须直连就得把星号改成external:*否则会把那个仓库的请求也强制代理掉导致解析失败。server 里 id 必须和 pom 里的仓库 id 一致这个 id 不是 host而是认证标识Nexus 在验证 deploy 请求时按它匹配用户名密码。发布构件需要项目pom.xml里配上distributionManagementdistributionManagement repository idmaven-releases/id urlhttp://192.168.1.10:8081/repository/maven-releases//url /repository snapshotRepository idmaven-snapshots/id urlhttp://192.168.1.10:8081/repository/maven-snapshots//url /snapshotRepository /distributionManagement执行mvn deploy时Maven 根据项目版本号最后是否带-SNAPSHOT自动选仓库不需要手工指定。带SNAPSHOT的版本走 snapshotRepository不带走 repository。如果两个地址都写成同一个 hosted 仓库轻则出现 release 仓库里混入开发包重则直接报 400。这个文件是开发者各配各的不要放到公共 settings.xml 里因为它描述的每个项目的发布目标和私有属性都不同。4. NPM 仓库实战npm publish、版本区分与 registry 指向4.1 建 NPM 仓库官方源做 proxyhosted 收上传NPM 在 Nexus 里的角色设计和 Maven 一致但默认仓库一个都没有全部需要手动建。先建代理仓库参数我的取值说明Namenpm-proxy代理远端 npm 源Remote Storagehttps://registry.npmjs.org官方源国内可换成淘宝镜像Blob Storenpm-blob依赖缓存独立存储Negative Cachetrue远端 404 也缓存减少重复请求再建一个 hosted 仓库参数较少但Strict Content Type Validation这个勾选要留意。这个选项开启后Nexus 会校验上传内容的格式是否符合 npm 规范避免有人误把临时文件传上来。我建议始终保持勾选关闭它确实能提升上传兼容性但也会让仓库里出现各种非 npm 垃圾数据。最后建 group 仓库把前两个聚合起来。成员顺序同样把 hosted 放在 proxy 之前这样私有包mycompany/utils和公共包lodash在同一个 registry 地址下npm 客户端不需要切换源。4.2 npm publish 全流程init、版本号与 registry 指向这个步骤回答一个高频疑问上传组件是先打包还是先执行npm init答案是先npm init。npm publish会自动把当前目录打包成 tarball 发送上去不需要手动npm pack之后再传包。发布包的名称和版本号全部来自package.json里的name和version字段这两个字段才是发布链路的源头。mkdir my-utils cd my-utils npm init -y npm pkg set namemycompany/utils version1.0.1 npm login --registryhttp://192.168.1.10:8081/repository/npm-hosted/ npm publish --registryhttp://192.168.1.10:8081/repository/npm-hosted/npm login需要输入 Nexus 用户名和密码成功后会把认证信息写进当前用户的.npmrc文件后续 publish 不需要重新认证。注意这里 registry 指向的是npm-hosted而不是 group 地址。hosted 才是唯一接受上传的仓库group 只读不写入往里 publish 会直接 403。版本区分靠package.json的version字段来控制。第一次上传 1.0.1第二次发版前先改版本号再发布npm version patch npm publish --registryhttp://192.168.1.10:8081/repository/npm-hosted/Nexus 对 npm 的版本保护是硬性的同一个版本号重复发布直接报409 Conflict提示不能覆盖已发布版本。所以不要靠“重新传一次”来纠正错误正确做法是在本地先把package.json版本号加一个然后把修复内容作为新版发布上去。对于正式包这个约束能保证任何依赖方拿到的版本不可变不会出现同一个版本号内容却不一样的情况。4.3 消费侧.npmrc 的 registry 和认证开发机安装依赖时registry 指向 group 地址这样公共包和私有包走同一个源registryhttp://192.168.1.10:8081/repository/npm-public/ //192.168.1.10:8081/repository/npm-public/:usernameadmin //192.168.1.10:8081/repository/npm-public/:_authTokenxxxx这个文件可以放在项目根目录也可以放在用户主目录的.npmrc。项目级优先于用户级用户级优先于全局配置。如果你不想手工编辑直接执行npm login --registryhttp://192.168.1.10:8081/repository/npm-public/工具会把 username 和 authToken 自动写入.npmrc输一次密码解决认证问题。需要注意npm config set registry改的是用户级配置对全局生效但也容易被项目级 .npmrc 覆盖。我习惯把 registry 写到项目级文件里这样同一台开发机上的不同项目可以用不同源互不干扰。如果哪天依赖拉取时报ETARGET或404第一反应是看当前目录的 .npmrc确认 registry 是不是跑到了别的地址上这是 npm 环境里最容易翻车的一个点。5. 避坑指南上传失败与进程挂掉的五个高频问题5.1 502 Bad GatewayJetty 线程池忙不过来现象几个同事同时跑npm install或mvn dependency:go-offlineNexus 页面和 API 请求集体变成 502重启后恢复第二天又复现。原因3.24 版本默认 Jetty 线程池配置偏保守并发请求一上来线程队列直接打满Jetty 无法继续接收连接。解决调整etc/jetty/jetty.xml里线程池的参数。常见做法是把最大线程数调到 200-300Configure idServer classorg.eclipse.jetty.server.Server Get nameThreadPool Set namemaxThreads300/Set Set nameminThreads10/Set Set nameidleTimeout60000/Set /Get /Configure改完重启 Nexus。不要一次性拉到 1000线程太多反而增大上下文切换开销。这个坑排查起来最费时间因为 502 会被误认为是网络问题或者服务挂掉实际上 Nexus 进程还活着只是端口不再接受新连接。5.2 npm publish 403发布地址写成了 group 仓库现象npm login成功npm publish却报403 Forbidden提示当前 registry 不允许写入。原因group 仓库是只读聚合入口上传请求只能落到 hosted 仓库。有人为了省事把.npmrc里的 registry 统一写成了 group 地址导致所有发布请求都被拒绝。解决发布时 registry 指向 hosted安装时指向 group两者不能混用。最稳妥的办法是在package.json里写死 publishConfig{ name: mycompany/utils, version: 1.0.2, publishConfig: { registry: http://192.168.1.10:8081/repository/npm-hosted/ } }这样即使开发者命令行里忘记带--registry参数发布请求也会自动走 hosted 仓库安装侧的.npmrc则继续保持 group 地址。5.3 mvn deploy 400SNAPSHOT 和 RELEASE 必须分开现象mvn deploy报400 Bad Request后台日志提示 Repository does not allow updating assets。原因版本号写成了固定版本如1.0.0但 pom 里的snapshotRepository配置或 distributionManagement 指向了 release 仓库。Nexus 的 release hosted 仓库默认不允许重复覆盖同时对快照版本有严格限制。解决开发阶段版本号必须带-SNAPSHOT后缀正式发布前改成不带后缀的固定版本。同时检查distributionManagement里两个 repository URL 是否分离release 指maven-releasessnapshot 指maven-snapshots。我见过最典型的错误是把两个 URL 写成了同一个地址开发阶段一直没事切到正式版第一次构建就 400。5.4 匿名访问把仓库细节全暴露了现象Nexus 管理界面不用登录就能看到所有仓库名称、最后更新时间甚至能浏览已发布的构件列表。原因安装完成后匿名访问默认是开启的3.24 版本的匿名角色在某些配置下还能执行读取之外的操作。很多内网部署没有主动去关它。解决进入 Settings 的 Security 菜单在 Anonymous Access 里取消勾选允许匿名用户访问然后到 Roles 里创建一个只读角色按需分配给服务账号。我现在的习惯是Nexus 只允许内网 IP 访问同时匿名访问直接关闭所有拉取依赖的请求都带账号凭证。这样就算某个开发机的配置泄露出去影响范围也能控制住。5.5 启动后进程秒退JDK 和磁盘都要查现象执行nexus start后进程很快消失ps -ef | grep nexus看不到任何结果日志文件也只有寥寥几行。原因最常见的是 JDK 版本不满足要求。3.24.0-02 需要 JDK 8用默认的 JDK 11 或更高版本启动时JVM 直接拒绝加载进程秒退。其次是 sonatype-work 所在分区磁盘满了嵌入式数据库初始化失败。解决先确认 Java 版本java -version看到版本号不是 1.8 开头就去bin/nexus脚本里设INSTALL4J_JAVA_HOME指向 JDK 8 安装路径。磁盘空间用df -h看sonatype-work 分区剩余空间至少要留几个 G。这两个都没问题就跑前台模式nexus run把完整异常输出打印出来比猜日志有用得多。6. 进阶技巧用 REST API 给 Nexus 做体检6.1 一键列出全部仓库repositories 端点管理界面右键一个个看仓库效率太低我部署完或者迁移完会用脚本批量对比。Nexus 3.24 自带 REST API不需要额外装插件。下面这段脚本列出所有仓库的格式、类型和名称#!/bin/bash NEXUS_URLhttp://192.168.1.10:8081 NEXUS_USERadmin NEXUS_PASS你的密码 curl -s -u $NEXUS_USER:$NEXUS_PASS \ $NEXUS_URL/service/rest/v1/repositories | \ python3 -c import sys, json data json.load(sys.stdin) for d in sorted(data, keylambda x: (x[format], x[type])): print(f\{d[format]:8s} {d[type]:8s} {d[name]}\) 这段脚本的返回结果是数组每个元素包含format、type、name、url等字段。format表示仓库格式如maven2、npmtype表示仓库类型如proxy、hosted、group。输出结果一眼就能看出来哪些格式还缺着尤其是 NPM 这种没有默认仓库的格式忘了建 proxy 在这个列表里立刻暴露。6.2 健康检查与版本确认v1/status 端点迁移或者升级之后我会用另一个接口确认当前实例的运行模式curl -s -u admin:你的密码 http://192.168.1.10:8081/service/rest/v1/status | python3 -m json.tool返回的 JSON 里有version字段确认当前版本号operationMode字段确认运行模式。单节点部署时operationMode是STANDALONE如果显示成集群模式但实际没有配置集群说明数据库配置文件有问题需要马上检查。从那以后我每次部署完 Nexus都会先跑一遍仓库列表脚本确认所有格式都建全了再交给团队。NPM 这种默认不带仓库的格式特别容易漏忘建 proxy 跑一遍 curl 就能发现。这套 REST 检查我换了三个环境都在用比盯着管理界面翻页靠谱。希望帮到你。本文还有配套的精品资源点击获取