企业官网建设流程全解析

简介：nexus-3.24.0-02-unix.tar.gz 是 Sonatype Nexus Repository Manager 3.24.0-02 针对 Unix/Linux 环境提供的官方安装包。它面向使用 Maven、Gradle 的 Java 开发团队，以及需要统一管理 NPM、NuGet 等软件构件的开发与运维人员，可帮助企业快速搭建私有的软件仓库，代理并缓存中央仓库依赖，解决公共仓库访问慢、组件来源分散与权限不可控等问题。 资源以单个 gz 压缩包形式提供，大小约 149.69MB，主要文件类型为 gz 压缩包；解压后包含 Nexus 服务程序目录和 sonatype-work 运行时数据目录，内置可执行文件、配置、库文件及索引、日志、存储结构，便于直接部署维护，也利于后续数据迁移与版本升级。目前已有 212 人学习/浏览。 借助该安装包，读者可获得一套可实际落地的企业级制品仓库基础环境。通过 Web 界面或配置文件，可完成端口、数据库与访问权限设置，创建 Maven 代理仓库和 NPM 私有仓库，并用仓库组统一入口；在 .npmrc 中将 Nexus 设为默认源后，团队即可集中拉取、缓存和发布组件，兼顾效率、安全与合规。

1. 拿到 nexus-3.24.0-02-unix.tar.gz 之后，别急着解压就完事

很多团队下载 nexus-3.24.0-02-unix.tar.gz 这个包，习惯是解压、启动、看到 8081 端口通了，就认为「私服装好了」。然后花两周时间在群里争论该用 Nexus 还是别的方案，最后把 Nexus 当成一个只能手动上传下载的文件柜用。这个 Unix 平台安装包真正值钱的地方，是它同时提供了三件事：代理远端仓库、本地缓存构件、给内网一个统一依赖入口。构建慢、外网源不稳定、或者需要隔离外网访问的团队，装上它之后能立刻感受到差别。

这篇笔记会按我自己给服务器部署的完整路径来写：装之前要做什么决定、最小安装怎么一次跑通、内存参数怎么调不翻车、第一个拉包仓库怎么建、哪些地方最容易踩坑。3.24.0-02 是一个偏保守的版本选择，但正因为保守，它在生产环境里的行为足够 predictable。下面每一步都是可复制执行的，新手照做能起来，熟手可以直接跳到第 4 章和第 5 章看调参和仓库配置边界。

2. 装之前先做三个决定：版本、JDK 与目录规划

2.1 为什么选 3.24.0-02 而不是追最新版

选择 3.24.0-02 不是因为它是新版本，恰恰相反，它属于依赖 JDK 8 这条成熟分支上的版本。新版 Nexus 对 JDK 版本要求高，很多服务器上现成的 JDK 8 环境根本带不动新版本，强行跑会出现类加载异常和各种奇怪警告。3.24.0-02 的典型场景是：服务器系统是多年没动的稳定发行版，内网策略保守，不希望因为装一个私服就去动全局 JDK。这类环境选它是对的。

另外一个实际原因是升级路径。Nexus 3 这个大版本内的数据目录格式基本兼容，3.24.0-02 后续可以平滑升到更新的 3.x 版本，不需要导出导入数据。也就是说，先用 3.24.0-02 把服务跑起来、把缓存积累起来，将来环境允许了再升级，数据不会变成黑匣子。相比之下，直接跨大版本升级要处理的风险点更多，第一次部署没必要给自己加难度。选型观点就一句：不追新，选自己环境里能稳定跑两年的版本。

2.2 JDK 版本与目录规划

3.24.0-02 官方要求 JDK 8，这一点在装之前就要确认。我遇到过有人在 JDK 11 上跑，服务能起来，但部分插件接口行为异常，排查起来非常费劲。稳妥做法是把 JDK 8 装好，并且把 JAVA_HOME 显式指过去。Nexus 自带的启动脚本会优先读取当前 shell 环境的 JAVA_HOME，指错了版本后面全是坑。

目录规划上要注意，这个包解压出来的目录和它的数据目录是分开的。程序目录是你解压 tar.gz 的位置（比如 /opt/nexus-3.24.0-02），数据目录默认在同一个父级下的 sonatype-work 文件夹里。数据目录里装着元数据库、二进制构件、日志和临时文件，生产环境一定把数据目录放到独立数据盘上，别跟系统盘挤在一起。磁盘满了比内存不足更难处理，因为日志和缓存会持续增长。

2.3 安装前的三条检查命令

# JDK 版本，确认默认版本是 8 java -version # 内存，确认至少 4G 可用，后面第 4 章会讲为什么 4G 是个临界值 free -m # 磁盘，确认数据盘剩余空间，建议至少给 20G 起步 df -h /opt && ulimit -n

这三条命令各有目的：java -version决定能不能继续；free -m看的是物理内存总量，因为 Nexus 的默认内存配置接近 5.4G，小内存机器按默认参数启动会直接失败；df -h /opt确认数据目录所在分区剩余空间，ulimit -n看文件描述符上限，低于 65535 时高并发拉包可能出现 Too many open files。如果 ulimit 偏低，需要在 /etc/security/limits.conf 里给运行用户调高，这步省略的话，后续仓库索引更新时进程会突然无响应。

3. 最小化安装：下载校验、解压与首次启动

3.1 下载与校验

从官方下载页拿到 3.24.0-02-unix.tar.gz 的直链后，用 wget 下载到服务器，并立刻做 SHA-256 校验。不要跳过这步，压缩包在传输过程中损坏的情况我遇到过两次，解压时报错不可怕，可怕的是解压成功但个别 jar 包已损坏，服务启动到一半才崩溃。

mkdir -p /opt/nexus && cd /opt/nexus # DOWNLOAD_URL 替换成你在官方下载页拿到的直链 wget "$DOWNLOAD_URL" -O nexus-3.24.0-02-unix.tar.gz # 对比官方提供的 SHA-256 校验值 echo "官方校验值 nexus-3.24.0-02-unix.tar.gz" | sha256sum -c -

这里的逻辑是把官方页面给出的哈希值字符串填入第一列，让sha256sum -c自动比对。校验值一致再继续，不一致就删掉重新下载。tar.gz 这种格式本身带 CRC 校验，但那只保证压缩流完整，不保证文件内容没被替换或源站出错，所以始终以官方哈希为准。

3.2 解压与目录结构说明

校验通过后解压，注意解压参数里不要带-C指定到已存在的旧目录，最好是全新目录。解压完确认目录结构再启动。

tar -xzf nexus-3.24.0-02-unix.tar.gz ls -la nexus-3.24.0-02/

解压出来的目录里，bin/下有启动脚本 nexux，lib/放着所有依赖的 jar 包，etc/下有配置文件，但真正需要手工改的配置文件极少。数据目录sonatype-work/nexus3/会自动生成在解压目录的同级位置，其中log/存放运行日志和 JVM 日志，admin.password是首次登录用的临时密码文件，db/是内嵌数据库目录。理解这几个路径对后面排错很重要，90% 的启动问题都写在log/目录里，而不是控制台。

3.3 前台启动验证与首次登入

第一次启动建议用前台模式，能直接看到日志滚动，方便确认有没有报错。

cd /opt/nexus/nexus-3.24.0-02 # 前台启动，观察启动日志 bin/nexus run

看到日志中出现Started Sonatype Nexus OSS才算真正启动完成。首次启动比后续启动慢很多，因为要初始化内嵌数据库和默认配置，机械盘上等三五分钟都正常。等到这个日志出现后，浏览器访问http://服务器IP:8081/，用admin登录，密码去读sonatype-work/nexus3/admin.password文件。

cat /opt/nexus/sonatype-work/nexus3/admin.password

登录后系统会强制改密码。这一步不要跳过，默认密码文件在首次登录成功后会删除，如果没改密码就关闭页面，再登录就只能去重置了。首次登录后顺手在设置里把匿名访问关掉，内网环境里默认开启匿名拉取虽然方便，但会让磁盘缓存不可控地增长。

4. 启动后的三件必做事：内存调参、服务托管与反向代理

4.1 nexus.vmoptions 里的三个必调参数

Nexus 3.24.0-02 默认内存配置写在一个叫nexus.vmoptions的文件里，位置在解压目录的bin/下。默认值对 4G 内存的机器非常不友好，直接按默认值启动会在 JVM 初始化阶段就失败。这个文件里最关键的是这三行：

-Xms2700M -Xmx2700M -XX:MaxDirectMemorySize=2700M

堆内存和直接内存各 2.7G，加起来 5.4G，这还没算 JVM 自身元空间和系统预留。4G 机器启动会直接报Could not reserve enough space for 3145728KB object heap。我一般会在 4G~8G 内存的机器上用下面这组配置：

# 4G 内存机器推荐配置 -Xms1024M -Xmx1024M -XX:MaxDirectMemorySize=768M -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=../sonatype-work/nexus3/log/jvm.log

调参逻辑是：堆内存给到物理内存的四分之一到三分之一，直接内存大约是堆的四分之三，剩下留给系统和 JVM 自身。不要只调-Xmx，MaxDirectMemorySize不跟着调的话，大量文件读写时会触发直接内存溢出，现象是上传构件时服务突然假死，但日志里看不到明显堆栈。改完配置必须重启服务才生效。

4.2 用 systemd 托管 Nexus 进程

bin/nexus start虽然能用，但它把进程挂在当前 shell 下，终端一关服务就没了。生产环境我用 systemd 托管，开机自启、崩溃自动拉起、日志统一管理都省心。下面是一份可用的 unit 文件：

cat > /etc/systemd/system/nexus.service <<'EOF' [Unit] Description=Nexus Repository Manager After=network.target [Service] Type=forking LimitNOFILE=65536 ExecStart=/opt/nexus/nexus-3.24.0-02/bin/nexus start ExecStop=/opt/nexus/nexus-3.24.0-02/bin/nexus stop User=nexus Restart=on-failure TimeoutStartSec=600 [Install] WantedBy=multi-user.target EOF

说明几个关键参数。Type=forking因为nexus start自身会 fork 出后台进程；LimitNOFILE=65536对应第 2 章说的文件描述符限制；User=nexus要提前创建好系统用户并给/opt/nexus目录授权，不能用 root 跑 Nexus，安全性和文件权限都会出问题；TimeoutStartSec=600很重要，默认 90 秒在慢机器上会误杀启动中的进程。写完执行systemctl daemon-reload && systemctl enable --now nexus即可。

useradd -r -s /sbin/nologin nexus chown -R nexus:nexus /opt/nexus systemctl daemon-reload && systemctl enable --now nexus

4.3 反向代理与上传大小限制

默认 8081 端口直连内网没问题，但团队里已经有统一网关时，让 Nexus 走反向代理更规范。配 nginx 时最容易忽略的是上传大小限制。nginx 默认client_max_body_size只有 1m，而 Nexus 上经常要推几百 MB 的安装包或容器镜像层，不调这个参数的话，上传到一半直接 413，日志里连 Nexus 的报错都看不到。

server { listen 8080; server_name nexus.internal.example; client_max_body_size 2048m; location / { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

proxy_pass指向本机 8081，client_max_body_size 2048m按团队实际最大构件尺寸调整。这里要提醒，如果之前用 8081 直连方式已经用了 Nexus 的默认地址，改成反向代理后仓库的 URL 会变，所有客户端配置都要跟着换。所以更省事的方案是一开始就确定访问入口，避免后期团队里一堆人改了配置又改回去。

5. 配置第一个 Raw 代理仓库并走通完整拉包链路

5.1 Blob Store：给存储定好边界

Nexus 3 的存储单位是 Blob Store，可以理解为一个独立的磁盘空间分区。默认会有一个文件类型的 Blob Store，但我建议每个仓库格式或团队单独建一个，方便做磁盘用量统计和清理策略。在管理界面左侧菜单进入 Repository → Blob Stores，点击 Create Blob Store，名字填raw-proxy-store，类型选 File，路径默认即可，会落在数据目录的 blob 文件夹下。

5.2 创建 Raw 代理仓库的完整步骤

用 Python 的包索引作为远程源是一个很适合演示的场景：包文件是静态二进制，没有复杂元数据依赖，正好体现 Raw 代理格式的本质。依次点击 Repository → Repositories → Create repository，选择raw (proxy)格式。关键配置项如下：

• Name：raw-pypi-proxy
• Remote storage：https://pypi.org/simple/
• Blob Store：选刚建的raw-proxy-store
• 在 HTTP 配置里加一个 User-Agent 请求头：Nexus/3.24.0

# 创建后立刻验证代理是否拉通了远端索引 curl -s -o /dev/null -w "%{http_code}\n" \ http://localhost:8081/repository/raw-pypi-proxy/simple/

返回 200 说明 Nexus 已经成功代理到了远端源。做这一步的意义是先把连通性确认了，再去配客户端。常见问题是 pypi 官方的 CDN 会拒绝不带 User-Agent 的请求，返回 403，导致 Nexus 代理一直失败。所以在 HTTP 配置里加 UA 是一个必要的细节，很多人漏了这一步，然后在客户端那边反复试错。

5.3 用 pip 客户端验证完整链路

服务端配好之后，本地一台开发机配置 pip 指向 Nexus 地址，验证真正拉包走的是缓存链路。

pip config set global.index-url http://<nexus地址>/repository/raw-pypi-proxy/simple/ pip config set global.index-url http://<nexus地址>/repository/raw-pypi-proxy/simple/ pip download --no-deps -d /tmp/pkgs requests

执行后看 Nexus 管理界面的日志或者直接看 sonatype-work 里的缓存文件增长。第一次下载后，第二次删掉本地~/.cache/pip再执行同样的命令，会发现速度明显快很多，因为构件已经从 Nexus 本地缓存命中了。Raw 格式代理不做元数据校验，远端返回什么它缓存什么，所以它能代理任何静态文件位置，这是它灵活的地方。

5.4 Raw 代理的边界与清理策略

Raw 代理格式有边界，必须讲清楚：它不具备 Maven 格式的版本解析能力。如果你把 pypi 源配成 raw 格式，pip 的版本依赖解析依然能工作，因为 Nexus 缓存的是 simple 索引页面和具体文件，解析逻辑由 pip 客户端完成。但如果你在 Maven 项目里用 raw 格式代理中央仓库，Gradle 或 Maven 的元数据解析就会失败，因为 raw 格式默认不处理 maven-metadata.xml 的增量更新。格式选错是新手最常犯的错，选型阶段就要想明白：需要解析元数据的生态用对应格式，纯静态文件用 raw。

清理策略也要提前定。默认不配 Cleanup Policy 的话，Blob Store 只增不减，时间长了磁盘会被撑爆。我在Repository → Cleanup Policies建过一条规则，按构件最后使用时间超过 30 天自动清理。Raw 代理仓库创建时在 Cleanup Policy 下拉里选上这条即可。这样缓存保留常用部分，冷数据自动释放。

6. 安装运维避坑指南：现象、原因与解决路径

6.1 启动后 503 端口通但页面打不开

现象是 8081 端口netstat能看到监听，但浏览器访问返回 503，管理界面一直转圈。原因是首次启动时内嵌数据库还在初始化，这个阶段 Nexus 会监听端口但还没有完成初始化。慢机器上这个过程长达数分钟，看起来像死掉了。解决方法是去看日志：

tail -f /opt/nexus/sonatype-work/nexus3/log/nexus.log

日志里出现Started Sonatype Nexus OSS之前，一切等待都是正常的。如果日志停在数据库相关的某一行超过 10 分钟不动，才是真的卡住，多半是磁盘 IO 问题或数据目录权限不对。

6.2 改了 vmoptions 后进程直接消失

现象是执行systemctl start nexus后等几秒，进程就退出了，systemctl status显示 exited。原因通常是把-Xmx调得过大，比如给 4G 机器设置 3G 堆内存，看起来没超过物理内存，但堆内存加上直接内存和 metaspace 的总需求超过了可用内存，JVM 初始化直接中止。解决方法是核对第 4.1 节的参数组合，并看一下 JVM 日志：

cat /opt/nexus/sonatype-work/nexus3/log/jvm.log

如果看到Could not reserve enough space for object heap，就是堆内存给多了；如果是Direct buffer memory相关，就是直接内存不足。按「物理内存的四分之一留系统」这个粗略算法重新配。

6.3 上传大构件报 413 Request Entity Too Large

现象看着像是 Nexus 拒绝了请求，实际是前置 web 服务器的限制。团队通过 nginx 反向代理访问 Nexus 时，nginx 默认只允许请求体 1MB，任何超过这个大小的上传都会在到达 Nexus 之前被拦截。原因就是没调client_max_body_size。解决方法是按第 4.3 节的配置把该参数调到大于实际最大构件尺寸，改完nginx -s reload立刻生效。

6.4 HTTPS 代理源 502 或握手失败

现象是代理仓库创建时 URL 填了https://开头的远端地址，首次拉取时反复失败，报 502 Bad Gateway。原因是 JDK 8 自带的 root CA 证书库比较旧，遇到新 CA 签发的域名或自签名证书时 SSL 握手失败。解决方式分两种：远端地址支持 HTTP 时暂时用 HTTP 验证连通性；必须用 HTTPS 时，把目标证书导入 JDK 的 cacerts：

keytool -importcert -trustcacerts -alias pypi \ -file pypi.crt -keystore $JAVA_HOME/jre/lib/security/cacerts

导入前先确认keytool用的是 Nexus 实际使用的 JDK 8 路径，导入到别的 JDK 里没有效果。这一步做完重启 Nexus 即可。

6.5 用 REST 接口给安装做一次最终体检

所有配置完成后，我用 REST 接口验证安装是否真正健康，而不是只凭页面能打开就宣布成功。Nexus 3.24 自带一组管理接口，不需要额外插件：

# 看系统状态，返回 online 表示运行正常 curl -s http://localhost:8081/service/rest/v1/status # 列出所有仓库，确认 raw-pypi-proxy 在列表里 curl -s http://localhost:8081/service/rest/v1/repositories \ | grep -o '"name" : "[^"]*"'

我自己的习惯是装完任何一台 Nexus 都跑一遍这两个请求，把结果留档。状态接口返回正常说明系统核心组件都在工作，仓库列表确认配置持久化成功。之后每隔一段时间看一次磁盘占用和jvm.log里的 WARNING，大部分隐患都能在变成事故之前发现。这套流程走了很多次，从下载校验到 REST 体检，每一步都是可重复的，照着做不会翻车。希望帮到你。

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