Decision: Static site on one server【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KGContextThe site publishes documentation and has no accounts.DecisionServe version-controlled static files with Nginx.ConsequencesSimple deployment and backupNo server-side formsOne-server availability boundaryRevisit WhenThe site needs authenticated or database-backed features.## 路径 A部署单台静态服务器 如果确认是静态站点按 [Prepare a Linux Web Server](https://link.gitcode.com/i/21ecdc892513604a9ac88904a40f876a) 和 [Deploy and Connect the Domain](https://link.gitcode.com/i/739257eeb4cc40de488859edb0835235) 执行。 ### 1. 准备服务器与 Nginx bash sudo apt update sudo apt upgrade在生产服务器上确认前先审阅包变更。然后安装并验证 Nginxsudo apt install nginx systemctl status nginx --no-pager sudo ss -lntpNginx 应监听 80 端口不要把无关的管理端口暴露到公网。创建站点目录示例值替换为你自己的域名sudo mkdir -p /var/www/example.dpdns.org sudo chown -R $USER:$USER /var/www/example.dpdns.org2. 配置虚拟主机创建/etc/nginx/sites-available/example.dpdns.orgserver { listen 80; listen [::]:80; server_name example.dpdns.org www.example.dpdns.org; root /var/www/example.dpdns.org; index index.html; location / { try_files $uri $uri/ 404; } access_log /var/log/nginx/example.dpdns.org.access.log; error_log /var/log/nginx/example.dpdns.org.error.log; }启用它配置测试必须成功才能 reloadsudo ln -s /etc/nginx/sites-available/example.dpdns.org /etc/nginx/sites-enabled/example.dpdns.org sudo nginx -t sudo systemctl reload nginx3. 先测服务器再动 DNS在改 DNS 之前从能访问该服务器的机器直接验证虚拟主机192.0.2.10替换为你的服务器 IPcurl -I -H Host: example.dpdns.org http://192.0.2.10这一步可以不等 DNS 生效就确认 Nginx 配置生效了。4. 上传文件并创建 DNS 记录如果服务器上已有旧内容先备份并记录当前 DNS 值以便恢复。在站点源目录的上级目录执行user192.0.2.10替换为你的服务器地址--delete会删除目标端本地不存在的文件确认好源和目标路径前可先省略该参数rsync -av --delete ./my-first-site/ user192.0.2.10:/var/www/example.dpdns.org/在服务器上确认文件与配置find /var/www/example.dpdns.org -maxdepth 2 -type f -print sudo nginx -t然后在外部权威 DNS 服务不是域名注册界面创建记录Name: Type: A Value: your-server-ipv4 Name: www Type: CNAME Value: example.dpdns.org只有服务器在 IPv6 上公网可达时才添加 AAAA 记录。5. 验证 DNS 与 HTTPdig A example.dpdns.org dig AAAA example.dpdns.org dig CNAME www.example.dpdns.org解析结果必须与真实可用的服务器地址一致IPv4/IPv6 都要分别测。然后curl -I http://example.dpdns.org curl -I http://www.example.dpdns.org两个名字都应到达目标服务器。DNS 查询成功但 HTTP 超时通常指向服务器、防火墙或路由问题。最后选定正式主机名注册域名或www在 HTTPS 对两个名字都配置好之后让另一个在 Web 服务器上重定向过去。如果部署失败恢复旧 DNS 值或旧文件让旧服务保持运行直到缓存的 DNS 答案过期并在重试前记录故障证据。路径 B同机加反向代理跑动态应用当站点需要账号、表单或动态数据时在静态路径基础上增加应用层。Dynamic Applications and Reverse Proxies 给出的常见架构Browser | | HTTPS :443 v Nginx reverse proxy | | HTTP on 127.0.0.1:3000 v Application process | v Database or external services反向代理负责终结 TLS、按主机名或路径路由、应用请求体大小与超时限制、高效服务静态文件、添加标准头、把应用端口移出公网。文档同时提醒它不会自动让不安全的应用变得安全。1. 应用只绑定本机回环如果只有反向代理需要访问应用优先让应用监听127.0.0.1:3000而不是0.0.0.0:3000并确认真实监听sudo ss -lntp2. 在 Nginx 中增加代理段文档给出的示例 location端口3000与应用实际端口一致时才可直接使用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; proxy_connect_timeout 5s; proxy_read_timeout 30s; }头信息的信任是应用层的决定要让应用只信任真实代理发来的代理头否则客户端可以伪造 scheme 和地址信息。3. 应用进程与配置的分界生产应用按文档需要非 root 服务账号、明确的工作目录、环境/密钥加载、带限制的自动重启、结构化日志、健康检查、优雅停机、部署与回滚流程。不要拿开发服务器当永久生产进程除非它的文档明确支持生产运行。配置要分成两类公开配置端口、功能开关、公开 URL和敏感配置数据库密码、签名密钥、API token。前端 bundle 是公开的嵌在浏览器 JavaScript 里的东西不算秘密。如果应用使用数据库除非需要远程访问否则绑定私有接口使用权限受限的专用数据库角色迁移走评审流程迁移前备份并且测试的是恢复而不是只测备份创建日志中避免写入密码、token 或完整个人信息。4. 健康检查与502排查建立一个不暴露秘密的轻量端点证明应用能处理请求GET /healthz - 200 OK要决定健康检查只验证进程还是连带数据库等依赖——深度检查可能产生负载或把依赖故障暴露给公网。出现502时文档给出的排查顺序确认应用进程在运行确认预期的本地端口在监听在服务器上直接请求应用查看反向代理错误日志查看应用日志核对proxy_pass的协议、地址和端口检查本地防火墙或安全策略。文档示例命令日志文件名替换为你站点实际的错误日志curl -I http://127.0.0.1:3000/healthz sudo tail -n 100 /var/log/nginx/example.dpdns.org.error.log什么时候才考虑多应用服务器文档对模式 4 的结论很直接多台服务器只有在状态、健康检查、部署、证书、依赖和故障切换都按设计落实时才提升可用性两台应用服务器挂在一个未监控的数据库和一个负载均衡器后面不算完整冗余。所以这不是多加一台机器的选项而是先补齐这些设计项否则停留在模式 1 或模式 2。配合 Reliability and Capacity Planning 的可用性预算做量级判断文档给出的近似值99% 对应 30 天约 7 小时 12 分钟停机99.9% 约 43 分钟99.99% 约 4 分 19 秒。目标会转化为监控和值守义务先定义可度量的目标再决定拓扑而不是只说网站应该永远可用。保持架构可迁移Website Architecture Patterns 建议从简单开始但保留边界让以后改架构不需要重写文档化域名与 DNS 归属源码放入版本控制使用稳定的公开 URL内容与密钥分离构建可复现并自动化备份独立于服务器监控用户可见的结果。另外文档要求为每个动态站点画出数据流并标注加密边界、认证决策点、个人数据、保留策略、第三方传输和管理访问User data - Browser - Public proxy - Application - Database - Logs - Backups验证顺序与边界无论选了哪种架构按 How a Website Request Works 的层次顺序逐层验证后一层修不好前一层的问题Registration - NS delegation - DNS record - Network port - TLS - HTTP - Application【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Decision: Static site on one server【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KGContextThe site publishes documentation and has no accounts.DecisionServe version-controlled static files with Nginx.ConsequencesSimple deployment and backupNo server-side formsOne-server availability boundaryRevisit WhenThe site needs authenticated or database-backed features.## 路径 A部署单台静态服务器 如果确认是静态站点按 [Prepare a Linux Web Server](https://link.gitcode.com/i/21ecdc892513604a9ac88904a40f876a) 和 [Deploy and Connect the Domain](https://link.gitcode.com/i/739257eeb4cc40de488859edb0835235) 执行。 ### 1. 准备服务器与 Nginx bash sudo apt update sudo apt upgrade在生产服务器上确认前先审阅包变更。然后安装并验证 Nginxsudo apt install nginx systemctl status nginx --no-pager sudo ss -lntpNginx 应监听 80 端口不要把无关的管理端口暴露到公网。创建站点目录示例值替换为你自己的域名sudo mkdir -p /var/www/example.dpdns.org sudo chown -R $USER:$USER /var/www/example.dpdns.org2. 配置虚拟主机创建/etc/nginx/sites-available/example.dpdns.orgserver { listen 80; listen [::]:80; server_name example.dpdns.org www.example.dpdns.org; root /var/www/example.dpdns.org; index index.html; location / { try_files $uri $uri/ 404; } access_log /var/log/nginx/example.dpdns.org.access.log; error_log /var/log/nginx/example.dpdns.org.error.log; }启用它配置测试必须成功才能 reloadsudo ln -s /etc/nginx/sites-available/example.dpdns.org /etc/nginx/sites-enabled/example.dpdns.org sudo nginx -t sudo systemctl reload nginx3. 先测服务器再动 DNS在改 DNS 之前从能访问该服务器的机器直接验证虚拟主机192.0.2.10替换为你的服务器 IPcurl -I -H Host: example.dpdns.org http://192.0.2.10这一步可以不等 DNS 生效就确认 Nginx 配置生效了。4. 上传文件并创建 DNS 记录如果服务器上已有旧内容先备份并记录当前 DNS 值以便恢复。在站点源目录的上级目录执行user192.0.2.10替换为你的服务器地址--delete会删除目标端本地不存在的文件确认好源和目标路径前可先省略该参数rsync -av --delete ./my-first-site/ user192.0.2.10:/var/www/example.dpdns.org/在服务器上确认文件与配置find /var/www/example.dpdns.org -maxdepth 2 -type f -print sudo nginx -t然后在外部权威 DNS 服务不是域名注册界面创建记录Name: Type: A Value: your-server-ipv4 Name: www Type: CNAME Value: example.dpdns.org只有服务器在 IPv6 上公网可达时才添加 AAAA 记录。5. 验证 DNS 与 HTTPdig A example.dpdns.org dig AAAA example.dpdns.org dig CNAME www.example.dpdns.org解析结果必须与真实可用的服务器地址一致IPv4/IPv6 都要分别测。然后curl -I http://example.dpdns.org curl -I http://www.example.dpdns.org两个名字都应到达目标服务器。DNS 查询成功但 HTTP 超时通常指向服务器、防火墙或路由问题。最后选定正式主机名注册域名或www在 HTTPS 对两个名字都配置好之后让另一个在 Web 服务器上重定向过去。如果部署失败恢复旧 DNS 值或旧文件让旧服务保持运行直到缓存的 DNS 答案过期并在重试前记录故障证据。路径 B同机加反向代理跑动态应用当站点需要账号、表单或动态数据时在静态路径基础上增加应用层。Dynamic Applications and Reverse Proxies 给出的常见架构Browser | | HTTPS :443 v Nginx reverse proxy | | HTTP on 127.0.0.1:3000 v Application process | v Database or external services反向代理负责终结 TLS、按主机名或路径路由、应用请求体大小与超时限制、高效服务静态文件、添加标准头、把应用端口移出公网。文档同时提醒它不会自动让不安全的应用变得安全。1. 应用只绑定本机回环如果只有反向代理需要访问应用优先让应用监听127.0.0.1:3000而不是0.0.0.0:3000并确认真实监听sudo ss -lntp2. 在 Nginx 中增加代理段文档给出的示例 location端口3000与应用实际端口一致时才可直接使用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; proxy_connect_timeout 5s; proxy_read_timeout 30s; }头信息的信任是应用层的决定要让应用只信任真实代理发来的代理头否则客户端可以伪造 scheme 和地址信息。3. 应用进程与配置的分界生产应用按文档需要非 root 服务账号、明确的工作目录、环境/密钥加载、带限制的自动重启、结构化日志、健康检查、优雅停机、部署与回滚流程。不要拿开发服务器当永久生产进程除非它的文档明确支持生产运行。配置要分成两类公开配置端口、功能开关、公开 URL和敏感配置数据库密码、签名密钥、API token。前端 bundle 是公开的嵌在浏览器 JavaScript 里的东西不算秘密。如果应用使用数据库除非需要远程访问否则绑定私有接口使用权限受限的专用数据库角色迁移走评审流程迁移前备份并且测试的是恢复而不是只测备份创建日志中避免写入密码、token 或完整个人信息。4. 健康检查与502排查建立一个不暴露秘密的轻量端点证明应用能处理请求GET /healthz - 200 OK要决定健康检查只验证进程还是连带数据库等依赖——深度检查可能产生负载或把依赖故障暴露给公网。出现502时文档给出的排查顺序确认应用进程在运行确认预期的本地端口在监听在服务器上直接请求应用查看反向代理错误日志查看应用日志核对proxy_pass的协议、地址和端口检查本地防火墙或安全策略。文档示例命令日志文件名替换为你站点实际的错误日志curl -I http://127.0.0.1:3000/healthz sudo tail -n 100 /var/log/nginx/example.dpdns.org.error.log什么时候才考虑多应用服务器文档对模式 4 的结论很直接多台服务器只有在状态、健康检查、部署、证书、依赖和故障切换都按设计落实时才提升可用性两台应用服务器挂在一个未监控的数据库和一个负载均衡器后面不算完整冗余。所以这不是多加一台机器的选项而是先补齐这些设计项否则停留在模式 1 或模式 2。配合 Reliability and Capacity Planning 的可用性预算做量级判断文档给出的近似值99% 对应 30 天约 7 小时 12 分钟停机99.9% 约 43 分钟99.99% 约 4 分 19 秒。目标会转化为监控和值守义务先定义可度量的目标再决定拓扑而不是只说网站应该永远可用。保持架构可迁移Website Architecture Patterns 建议从简单开始但保留边界让以后改架构不需要重写文档化域名与 DNS 归属源码放入版本控制使用稳定的公开 URL内容与密钥分离构建可复现并自动化备份独立于服务器监控用户可见的结果。另外文档要求为每个动态站点画出数据流并标注加密边界、认证决策点、个人数据、保留策略、第三方传输和管理访问User data - Browser - Public proxy - Application - Database - Logs - Backups验证顺序与边界无论选了哪种架构按 How a Website Request Works 的层次顺序逐层验证后一层修不好前一层的问题Registration - NS delegation - DNS record - Network port - TLS - HTTP - Application【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
