网站源码怎么部署到服务器上：从上传到访问

把网站源码放到服务器上，并不等于网站已经可以访问。通常还要确认源码类型、准备运行环境、配置 Web 服务器、开放网络端口，并让域名指向服务器。部署流程因静态网页、PHP 程序和 Node.js 应用而不同；如果把适用于一种项目的命令照搬到另一种项目上，常见结果就是访问到目录列表、出现 403，或看到服务器返回 502。

本文以常见的 Ubuntu/Debian Linux 云服务器为例，说明从准备服务器、上传文件，到配置 Nginx、绑定域名和启用 HTTPS 的过程。示例适合有 SSH 管理权限的服务器。使用虚拟主机面板、容器平台或托管服务时，部分步骤应改用相应平台提供的部署方式。

一、先确认源码属于哪一类

部署前先看项目文件和运行说明，而不是先把整个源码目录上传到网站根目录。

静态网站：通常包含 HTML、CSS、JavaScript 和图片，浏览器直接读取构建后的文件。若项目使用 Vue、React 等构建工具，通常需要先执行构建，再部署生成目录，例如 dist 或 build。
PHP 网站：需要 PHP 运行环境，常见搭配是 Nginx 与 PHP-FPM。仅安装 Nginx 并上传 PHP 文件，不会自动执行 PHP。
Node.js 等后端应用：需要安装对应运行时、安装依赖、启动应用，并由 Nginx 将外部请求转发给应用。将源码上传到 Nginx 网站目录本身，并不能启动服务。
依赖数据库或其他服务的项目：还要准备数据库、缓存、环境变量、文件存储等，并配置连接信息。不要假设开发环境里的数据库和本地配置会自动出现在服务器上。

优先阅读项目中的 README、部署文档和依赖清单，确认启动命令、构建命令、运行时版本、监听端口及配置项。本文主要介绍自行管理 Linux 服务器的做法，不适用于没有 SSH 权限的普通虚拟主机，也不意味着所有框架都能用同一份 Nginx 配置运行。

二、准备服务器、域名和本地构建产物

1. 确认服务器访问条件

准备一台运行受支持 Linux 发行版的服务器，并记录公网 IP。通过 SSH 登录通常使用服务器提供的用户名和 SSH 密钥；不同云厂商可能使用不同默认账号，具体以服务商文档为准。下面以已经能够通过 SSH 登录为前提。

ssh deploy@SERVER_IP

将 deploy 和 SERVER_IP 替换为实际用户名与 IP。如果使用非默认 SSH 端口，可加上 -p 端口号。建议使用普通用户执行日常操作，需要系统权限时再使用 sudo，不要把网站进程直接配置为 root 运行。

先更新系统软件包索引并安装 Nginx。不同发行版、软件源和版本可能提供不同版本的软件；生产环境应按项目兼容要求选择版本，并及时安装安全更新。

sudo apt update
sudo apt install nginx
sudo systemctl enable --now nginx
sudo systemctl status nginx

云平台的安全组和服务器本机防火墙是两道不同的网络控制。需要确保外部可以访问 TCP 80 和 TCP 443；SSH 端口则应按管理需要开放给可信来源。以启用了 UFW 的 Ubuntu 为例：

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw status

启用防火墙前，应先确认 SSH 规则已经允许当前管理连接，否则可能把自己锁在服务器外。若服务器使用其他防火墙或云平台安全组，还要在相应位置配置规则。不要为了方便而开放所有端口。

2. 准备域名解析

如果要通过域名访问，需在域名 DNS 管理处添加记录：通常给主域名添加指向服务器公网 IPv4 地址的 A 记录；若使用 IPv6，则配置匹配服务器地址的 AAAA 记录。二级域名也可以使用 A 记录或指向主域名的 CNAME，具体取决于 DNS 服务商规则。DNS 生效时间受解析缓存和 TTL 影响，不保证修改后立即全球同步。

还没有域名时，可以先用 IP 测试 Nginx 是否可达，但 HTTPS 证书通常要为域名签发。不要在域名还指向其他服务器时，误以为新服务器的配置已经生效。

三、构建并上传静态网站

1. 在本地生成可发布文件

如果项目是纯静态页面，确认入口文件通常是 index.html。如果项目需要构建，先根据项目说明安装相应版本的 Node.js 和包管理器，再在项目目录执行构建命令。以下是常见命令示例，不代表每个项目都使用 npm：

npm install
npm run build

检查项目说明中的构建脚本和输出目录。只应上传构建后的发布文件及运行所需资源；源码中的开发依赖、版本控制目录、本地环境文件和测试数据通常不需要放到公开网站目录。某些项目需要调整构建时的站点路径或 API 地址，应先按其文档配置。

2. 在服务器创建网站目录

为示例域名 example.com 创建独立目录，并让部署用户可以上传、Nginx 可以读取：

sudo mkdir -p /var/www/example.com
sudo chown -R deploy:www-data /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 755 {} \;
sudo find /var/www/example.com -type f -exec chmod 644 {} \;

这里假设部署用户是 deploy，Nginx 工作组是 www-data；其他 Linux 发行版或安装方式可能使用不同的用户组，应先确认实际配置。目录权限 755、普通文件权限 644 是静态文件的常见起点，不是适合所有项目的固定规则。不要使用 chmod -R 777：这会让所有本机用户都能写入相关文件，扩大被篡改的风险。

3. 使用 rsync 上传

在本地电脑执行上传命令。将 dist/ 换成实际构建输出目录，将服务器地址和用户名换成自己的：

rsync -avz --delete ./dist/ deploy@SERVER_IP:/var/www/example.com/

源路径末尾的斜杠表示同步 dist 目录中的内容，而不是把目录本身再嵌套一层。--delete 会删除服务器目标目录中、源目录没有的文件，适合需要让目标与本地发布目录一致的场景，但用错路径可能删除目标目录里的内容。第一次部署或尚未确认路径时，先去掉该参数；也可以先检查将发生的变更：

rsync -avzn --delete ./dist/ deploy@SERVER_IP:/var/www/example.com/

选项 -n 表示试运行，不实际执行同步。还可以用 SSH 完成简单复制，但 rsync 更方便增量传输；部署前仍应保留可以恢复的旧版本。上传后检查服务器上是否确实存在入口文件：

ls -la /var/www/example.com

四、配置 Nginx 提供静态文件

创建一个独立的 Nginx 站点配置。以下示例将 HTTP 请求指向 /var/www/example.com，并关闭目录列表。它适合普通静态网站；如果网站使用客户端路由，可能还要配置前端路由回退。

sudo tee /etc/nginx/sites-available/example.com >/dev/null <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ /\.(?!well-known) {
        deny all;
    }
}
EOF

将 server_name 换成实际域名；如果不使用 IPv6，应按服务器网络情况检查是否保留 IPv6 监听。启用配置前测试语法：

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
sudo nginx -t
sudo systemctl reload nginx

如果默认站点也响应同一个请求，可能会看到 Nginx 欢迎页或错误站点。先检查其他站点配置的 server_name、默认服务器设置和启用的符号链接，不要为了“让配置生效”而无差别删除系统文件。

对于 Vue Router、React Router 等前端单页应用，刷新诸如 /about 的路由时，Nginx 默认会尝试查找服务器上的同名文件，因而可能返回 404。若该项目确实需要由前端路由处理不存在的路径，可将对应位置改为：

location / {
    try_files $uri $uri/ /index.html;
}

这项回退会把未找到的路径交给 index.html，但不适用于所有网站。例如服务端页面或需要真实 404 状态码的网站，可能不应这样配置。还应避免让未知的敏感文件通过通用静态规则被下载。

五、PHP 和 Node.js 项目需要额外处理什么

PHP：Nginx 不会直接执行 PHP

PHP 项目需要安装与项目兼容的 PHP 版本、扩展和 PHP-FPM，并配置 Nginx 把 PHP 请求交给 FPM。不同发行版的 FPM socket 文件路径、服务名称和 PHP 版本都可能不同，不能盲目复制某个版本号。安装后先查明实际 socket，例如查看 PHP-FPM 服务状态及其监听配置，再据此设置 fastcgi_pass。

以下是结构示意，不可直接当成所有服务器通用的完整配置；示例中的 socket 路径必须替换成服务器真实路径。网站根目录也应按框架文档设置，某些 PHP 框架的公开入口位于 public 子目录，而不是项目根目录。

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }

    location ~ /\.(?!well-known) {
        deny all;
    }
}

要根据框架路由、PHP-FPM 配置和发行版文档核对指令，测试 Nginx 配置后再重载。数据库密码、应用密钥等不能放在可被 Web 服务器直接下载的位置。生产环境也不应公开 PHP 的错误详情或调试页面。

Node.js：运行应用，再由 Nginx 反向代理

常见做法是让 Node.js 应用仅监听本机回环地址和一个内部端口，再让 Nginx 对外接收 HTTP/HTTPS 并转发请求。这样通常不必把应用端口直接开放给公网。端口号、监听参数和启动脚本必须按框架要求调整；有些框架通过环境变量指定监听地址，有些需要命令行参数。

先确认服务器安装了项目支持的 Node.js 版本，然后在项目目录按锁文件和项目说明安装生产依赖、构建并测试启动命令。不要把开发服务器当成生产服务的默认方案；应采用框架推荐的生产启动方式，并确认应用崩溃后能自动恢复。

可用 systemd 管理应用进程。下面是一个示例单元文件，假设项目位于 /var/www/myapp，运行用户为 app，且 npm start 能以生产模式启动应用。使用前要创建该用户、确认目录权限和实际命令路径，并按项目设置环境变量：

[Unit]
Description=My Node.js application
After=network.target

[Service]
Type=simple
User=app
WorkingDirectory=/var/www/myapp
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=/usr/bin/npm start
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

将内容保存为 /etc/systemd/system/myapp.service 后，可执行：

sudo systemctl daemon-reload
sudo systemctl enable --now myapp
sudo systemctl status myapp

/usr/bin/npm 是否存在取决于安装方式；先用 command -v npm 核对。若使用 Node 版本管理工具，systemd 的运行环境通常不会自动加载交互式 shell 配置，需要明确设置正确的运行时路径。不要把数据库密码直接写进可被普通用户读取的单元文件；可使用权限受限的环境文件，并确保文件没有被放进网站公开目录。

应用稳定监听本机 127.0.0.1:3000 后，可以在 Nginx 的站点配置中反向代理：

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    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_set_header X-Forwarded-Proto $scheme;
}

若项目使用 WebSocket、上传大文件或需要特殊超时，还可能要添加相应配置。代理头的信任方式也要符合应用框架要求；不要因为客户端可以发送类似头部，就在应用层无条件信任所有转发信息。

六、启用 HTTPS 并确认站点可访问

在申请证书前，先确认域名已经解析到这台服务器，80 端口可以从公网访问，Nginx 的 server_name 也与域名一致。Ubuntu/Debian 上常见做法是使用 Certbot 的 Nginx 插件；安装方式和版本会因发行版及软件源而异，应参考 Certbot 对应系统的安装说明。安装完成后通常可运行：

sudo certbot --nginx -d example.com -d www.example.com

该命令仅在安装了 Certbot 和 Nginx 插件、域名验证条件满足且 Nginx 配置可用时适用。证书申请失败时，先检查 DNS、80 端口、安全组、域名拼写和站点配置。不要把证书私钥上传到公开目录或提交进代码仓库。签发后可以检查自动续期配置，并进行模拟续期测试：

sudo certbot renew --dry-run

部署完成后，分别检查 HTTP/HTTPS、域名解析和页面资源加载。服务器本机可用 curl 查看响应，外部网络也应实际访问验证：

curl -I http://example.com
curl -I https://example.com
sudo nginx -t
sudo systemctl status nginx

如果页面打开但 CSS、JavaScript 或图片缺失，检查浏览器开发者工具中的请求地址和状态码。常见原因包括构建时使用了错误的资源基础路径、大小写不匹配、上传目录多了一层，以及 HTTPS 页面引用了 HTTP 资源。

七、常见错误与定位顺序

看到 Nginx 欢迎页：检查域名是否指向正确 IP、对应站点配置是否启用、server_name 是否匹配，以及默认站点是否先匹配请求。
403 Forbidden：确认入口文件存在，并检查 Nginx 对文件及其上级目录是否有读取和遍历权限。不要直接把权限改为 777。
404 Not Found：核对 Nginx 的 root、上传路径和入口文件；前端单页应用还需判断是否需要路由回退。
502 Bad Gateway：多见于反向代理后端没有启动、端口不一致、应用只监听了错误地址，或 PHP-FPM socket 配置错误。先检查应用服务状态和日志，再检查 Nginx 错误日志。
域名无法访问：核对 DNS 记录、公网 IP、云安全组和本机防火墙。DNS 修改可能仍处于缓存传播期；仅在本机能访问并不能证明公网端口已开放。
上传后仍是旧页面：确认文件上传到了当前 Nginx 配置所指向的目录，排查浏览器缓存、CDN 缓存和应用自身缓存，再确认是否需要重新构建或重载服务。
配置改完网站中断：每次重载前先执行 sudo nginx -t。测试失败时不要继续重载，应修复语法或恢复上一版配置。

Nginx 日志通常位于 /var/log/nginx/，常见文件名是 access.log 和 error.log；实际路径以服务器配置为准。查看最近的错误记录：

sudo tail -n 100 /var/log/nginx/error.log

systemd 服务的输出可通过 journalctl 查看，例如：

sudo journalctl -u myapp -n 100 --no-pager

排错时按“域名解析和网络—Nginx 配置与日志—应用进程与日志—文件权限和资源路径”的顺序检查，通常比反复重启更快找到原因。命令中的服务名称和日志路径可能因系统而异。

八、上线前的安全检查和后续维护

网站目录只放需要公开访问的文件。环境配置、数据库备份、源码仓库元数据、私钥和部署凭证不应暴露在 Web 根目录。
使用最小权限：应用只获得运行所需的文件访问权限；需要写入的上传目录与程序代码目录尽量分开。
关闭调试模式和开发测试账号，设置强且独立的管理凭证。程序依赖、操作系统和数据库都应按维护计划更新。
备份不只是复制网页文件。动态网站通常还要备份数据库、用户上传内容及关键配置，并定期验证能够恢复。
部署时保留旧版本或可重建的发布产物。新版本出错时，应能恢复文件、数据库变更和服务配置；数据库结构变更尤其需要提前设计兼容和回滚方案。
关注访问日志、错误日志、磁盘空间和证书续期状态。生产网站应有明确的故障告警与恢复责任人。

对于个人静态站点，常见路径是“本地构建—rsync 上传—Nginx 提供文件—配置域名和 HTTPS”；对于 PHP 或 Node.js 应用，关键差异在于服务器必须运行相应的应用进程，并安全地处理配置、日志、写入目录和数据库连接。掌握这些边界后，再按项目文档调整运行时、构建工具和 Web 服务器配置，才能避免把“文件已经上传”误当成“网站已经部署完成”。

AIGC人工智能 # 网站源码

文章版权归作者所有，未经允许请勿转载。

网站源码怎么部署到服务器上：从上传到访问

网站源码怎么部署到服务器上：从上传到访问

一、先确认源码属于哪一类

二、准备服务器、域名和本地构建产物

1. 确认服务器访问条件

2. 准备域名解析

三、构建并上传静态网站

1. 在本地生成可发布文件

2. 在服务器创建网站目录

3. 使用 rsync 上传

四、配置 Nginx 提供静态文件

五、PHP 和 Node.js 项目需要额外处理什么

PHP：Nginx 不会直接执行 PHP

Node.js：运行应用，再由 Nginx 反向代理

六、启用 HTTPS 并确认站点可访问

七、常见错误与定位顺序

八、上线前的安全检查和后续维护

如何下载网站源码并在本地运行

SQL数据库入门：从建表到查询的基础操作

相关文章

揭秘十二星座的情感奥秘：豪华版配对分析 (揭秘十二星座最真实的性格)

AI生成淘宝主图怎么写提示词？白底图、卖点图都能用

【性格解析】双子座女生的多面性格：灵活思想家与敏锐观察者，为何她们总是能迅速适应各种社交场合 (不喜欢花的女人性格解析)

天秤座：天空中优雅与平衡的守护者 (天秤座天空星座图)

热门网址

网址

末日动漫

BT吧

无极磁链

人民网

Similarsites

电影导航

最新资讯

网站源码怎么部署到服务器上：从上传到访问

网站源码怎么部署到服务器上：从上传到访问

一、先确认源码属于哪一类

二、准备服务器、域名和本地构建产物

1. 确认服务器访问条件

2. 准备域名解析

三、构建并上传静态网站

1. 在本地生成可发布文件

2. 在服务器创建网站目录

3. 使用 rsync 上传

四、配置 Nginx 提供静态文件

五、PHP 和 Node.js 项目需要额外处理什么

PHP：Nginx 不会直接执行 PHP

Node.js：运行应用，再由 Nginx 反向代理

六、启用 HTTPS 并确认站点可访问

七、常见错误与定位顺序

八、上线前的安全检查和后续维护

如何下载网站源码并在本地运行

SQL数据库入门：从建表到查询的基础操作

相关文章

揭秘十二星座的情感奥秘：豪华版配对分析 (揭秘十二星座最真实的性格)

AI生成淘宝主图怎么写提示词？白底图、卖点图都能用

【性格解析】双子座女生的多面性格：灵活思想家与敏锐观察者，为何她们总是能迅速适应各种社交场合 (不喜欢花的女人性格解析)

天秤座：天空中优雅与平衡的守护者 (天秤座天空星座图)

热门网址

网址

末日动漫

BT吧

无极磁链

人民网

Similarsites

电影导航

最新资讯

标签云