tva
← 洞察

CloudPanel 性能优化：提升 Hetzner 云服务器性能与网站响应速度

当性能瓶颈出现时，在单台服务器上自托管多个网站的难度将呈指数级增长。CloudPanel 简化了网站管理，但实现最佳性能需要远超默认配置的系统化服务器优化。如果您曾经历过响应时间缓慢、服务器负载过高或网站性能不稳定，本综合指南将帮助您将 CloudPanel 部署转变为高性能托管平台。

您将实现的目标

通过实施这些经过验证的优化，您将获得：

  • 在我们的生产环境中，TTFB（首字节时间）提速最高可达 85%
  • 通过智能资源分配节省 500-1000MB 内存
  • 消除冷启动延迟，实现即时网站响应
  • TTFB 低于一秒（我们在生产环境中的测量值为 0.15-0.7 秒）
  • 无需昂贵硬件升级即可实现经济高效的扩展
  • 无论流量模式如何，始终保持全天候优化性能
  • 通过适当的资源管理实现生产级可靠性

CloudPanel 性能挑战

传统性能痛点

大多数 CloudPanel 安装都存在常见的性能瓶颈：

  • PHP-FPM 池过大：默认配置分配了过多资源
  • MySQL 缓冲池效率低下：数据库缓存不足以匹配服务器容量
  • 冷启动延迟：PHP 进程退出过快，导致响应延迟
  • 内存浪费：默认 768MB 内存限制，而 256MB 即可满足需求
  • 进程管理效率低下：采用空闲超时较短的按需进程创建方式，而非保持进程预热的动态进程池

业务影响

服务器性能不佳直接影响您的业务：

  • 客户留存：响应变慢会降低转化率
  • SEO 排名：Google Core Web Vitals 直接影响搜索可见性
  • 基础设施成本：不必要的服务器升级取代了优化
  • 运营开销：手动扩展和持续的故障处理

服务器评估：识别性能瓶颈

系统资源分析

从全面的服务器分析开始，识别主要瓶颈：

# Check overall system health
uptime && free -h

# Identify resource-hungry processes
ps aux --sort=-%mem | head -20
ps aux --sort=-%cpu | head -20

# MySQL/MariaDB performance analysis
systemctl status mysql

关键预警信号

关注以下性能指标：

  • MySQL CPU 使用率 > 40%：需要数据库优化
  • 每个网站 PHP-FPM 进程 > 100：池配置过大
  • 平均负载 > CPU 核心数：系统承受压力
  • 可用内存 < 30%：内存压力影响性能
  • TTFB > 500 毫秒：存在显著的优化空间

数据库大小分析

过大的数据库会产生级联性能问题：

# Analyze database storage consumption
du -sh /var/lib/mysql/*/ | sort -hr | head -10

# Identify problematic tables
ls -laS /var/lib/mysql/database_name/*.ibd | head -10

正常与异常数据库大小对比：

  • 典型 WordPress：2-50MB
  • 电商网站：50-200MB
  • 复杂应用：200-500MB
  • 🚨 性能告警：> 1GB（需要优化）

MySQL/MariaDB 优化：数据库性能基础

缓冲池优化

最关键的 MySQL 优化涉及正确的缓冲池大小设置：

# Backup current configuration
cp /etc/mysql/mysql.conf.d/mysqld.cnf /etc/mysql/mysql.conf.d/mysqld.cnf.backup.$(date +%Y%m%d)

# Edit MySQL configuration
nano /etc/mysql/mysql.conf.d/mysqld.cnf

优化的 MySQL 配置：

[mysqld]
# Performance optimizations
innodb_buffer_pool_size = 3G          # 20% of total RAM for 15GB server
innodb_io_capacity = 1000             # SSD-optimized I/O
innodb_flush_method = O_DIRECT        # Bypass OS file cache
innodb_buffer_pool_instances = 8      # Multiple instances for better concurrency

# Query performance
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

# Connection optimization
max_connections = 512
thread_cache_size = 32
table_open_cache = 2048

# Memory allocation
join_buffer_size = 8M
tmp_table_size = 128M
max_heap_table_size = 128M

验证与重启

# Test configuration validity
mysqld --validate-config

# Apply changes
systemctl restart mysql

# Verify optimization
systemctl status mysql
ps aux | grep mysql

预期结果：

  • 可预测的内存使用量：大致为 3G 缓冲池加上全局缓冲区和每个连接的缓冲区
  • CPU 利用率下降：40%+ → 5-15%
  • 查询响应改善：数据库操作速度提升 50-80%

PHP-FPM 优化：消除应用瓶颈

全局内存限制优化

CloudPanel 默认的 768MB 内存限制允许单个失控的 PHP 请求消耗远超大多数网站所需的 RAM。降低该限制可以约束每个进程在最坏情况下的用量，但不会释放进程并未使用的内存：

# Backup PHP configuration
cp /etc/php/8.0/fpm/php.ini /etc/php/8.0/fpm/php.ini.backup.$(date +%Y%m%d)

# Optimize global memory limit
sed -i 's/memory_limit = 768M/memory_limit = 256M/' /etc/php/8.0/fpm/php.ini

# Test and restart
php-fpm8.0 -t
systemctl restart php8.0-fpm

高级池配置：动态进程管理

将每个网站从按需创建进程改为使用保持预热状态、可动态扩展的进程池：

存在问题的默认配置：

pm = ondemand              ; ❌ Cold-start latency
pm.max_children = 250      ; ❌ Extreme overallocation  
pm.process_idle_timeout = 10s  ; ❌ Processes die too quickly
pm.max_requests = 100      ; ❌ Short process lifecycle

性能优化后的配置：

[website_pool_name]
listen = 127.0.0.1:PORT
user = website_user
group = website_group

; Dynamic process management for optimal performance
pm = dynamic
pm.max_children = 60               ; Maximum concurrent processes
pm.start_servers = 12              ; Always-warm processes for instant response
pm.min_spare_servers = 8           ; Minimum ready processes
pm.max_spare_servers = 20          ; Scale up to this during traffic spikes
pm.process_idle_timeout = 300s     ; Keep processes alive for 5 minutes
pm.max_requests = 1000             ; Long-lived processes reduce overhead

; Advanced performance settings
listen.backlog = 65535
request_terminate_timeout = 7200s
rlimit_files = 131072
catch_workers_output = yes

; Memory and execution optimization
php_admin_value[memory_limit] = 256M
php_admin_value[max_execution_time] = 60
php_admin_value[opcache.enable] = 1
php_admin_value[opcache.memory_consumption] = 128
php_admin_value[opcache.max_accelerated_files] = 10000

批量池优化策略

对于托管多个网站的 CloudPanel 服务器，系统化优化可带来最大效果：

# Identify all website pools
ls /etc/php/8.0/fpm/pool.d/*.conf | grep -v -E "(default|global)" | wc -l

# Create backup directory
mkdir -p /root/php-pool-backup-$(date +%Y%m%d-%H%M)
cp /etc/php/8.0/fpm/pool.d/*.conf /root/php-pool-backup-$(date +%Y%m%d-%H%M)/

# Apply optimizations to each website pool
# (Repeat for each website configuration file)

性能影响计算（最坏情况下，每个进程均达到 256MB 的 memory_limit；实际的单进程用量通常远低于此，因此应根据实测的进程内存用量和服务器 RAM 设置进程池大小）：

  • 优化前：25 个网站 × 250 进程 × 256MB = 1.6TB 潜在内存使用
  • 优化后：25 个网站 × 60 进程 × 256MB = 384GB 理论上限
  • 基线：25 个网站 × 12 进程 × 256MB = 常驻预热进程的 77GB 理论上限

高级性能策略

全天候全球优化方法

与传统的基于时间的扩展不同，服务全球用户的网站需要一致的性能：

为什么全天候优化至关重要：

  • 全球用户群：服务多个时区时没有真正的“低峰时段”
  • 搜索引擎抓取：爬虫在不可预测的时间访问网站
  • 业务连续性：专业网站必须保持响应能力
  • 竞争优势：持续的性能胜过间歇性的速度

实施策略：

  • 基于负载的动态扩展取代基于时间的扩展
  • 始终预热的进程池实现即时响应
  • 基于实际使用模式的智能资源分配
  • 流量高峰期间的自动扩展

PHP OPcache 优化

通过字节码缓存加速 PHP 执行。设置 opcache.validate_timestamps = 0 后，PHP 将不再检测文件变更，因此每次部署后都需要重新加载 PHP-FPM 或重置 OPcache：

; Add to each PHP-FPM pool configuration
php_admin_value[opcache.enable] = 1
php_admin_value[opcache.memory_consumption] = 128
php_admin_value[opcache.interned_strings_buffer] = 16
php_admin_value[opcache.max_accelerated_files] = 10000
php_admin_value[opcache.validate_timestamps] = 0
php_admin_value[opcache.save_comments] = 1

数据库查询优化

监控和优化有问题的数据库查询：

# Enable slow query monitoring
tail -f /var/log/mysql/slow.log

# Identify performance bottlenecks
mysql -e "SHOW PROCESSLIST;"

# Optimize problematic tables
mysql -e "ANALYZE TABLE database_name.table_name;"

性能测试与验证

TTFB（首字节时间）测量

测量影响用户体验的关键性能指标：

# Single website test
curl -w "TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" -o /dev/null -s https://your-website.com

# Comprehensive testing
for site in website1.com website2.com website3.com; do
  echo "Testing $site:"
  for i in {1..3}; do
    curl -w "Test $i - TTFB: %{time_starttransfer}s\n" -o /dev/null -s https://$site
  done
  echo "---"
done

系统资源监控

跟踪优化对服务器资源的影响：

# Monitor active PHP processes
ps aux | grep "php-fpm: pool" | grep -v grep | wc -l

# Check memory utilization
free -h

# Verify MySQL performance
systemctl status mysql --no-pager

预期性能改善

来自生产环境的真实优化结果：

指标优化前优化后改善幅度
平均 TTFB1.5-3.0 秒0.15-0.7 秒提速 85%
MySQL CPU 使用率40-90%5-15%降低 75%
可用内存2-4GB8-12GB增加 200%
PHP 进程数每站 300+每站 12-60减少 80%
冷启动延迟2-5 秒已消除即时响应

正在规划全面的服务器性能优化，但担心实施复杂性或潜在的停机时间？我们的基础设施团队专注于 CloudPanel 性能调优 – 我们可以在尽量减少服务中断的情况下实施这些优化，同时监控每一步以确保最佳结果。

高级数据库清理策略

WordPress 数据库优化

过大的 WordPress 数据库会严重影响性能。常见原因和解决方案：

有问题的数据库元素：

  • 文章修订版本：每篇文章/每个页面的多个版本
  • 孤立元数据：删除内容后的残留数据
  • 临时缓存：过期临时数据的积累
  • 插件残留：停用后未清除的插件数据

安全清理方法：

  1. 在任何修改前完整备份数据库
  2. 分析查询以识别清理机会
  3. 渐进式清理而非激进删除
  4. 在整个过程中进行性能监控
-- Analyze database bloat (read-only queries)
SELECT table_name, 
       ROUND(((data_length + index_length) / 1024 / 1024), 2) AS "Size_MB"
FROM information_schema.tables 
WHERE table_schema = 'your_database_name'
ORDER BY Size_MB DESC;

-- Identify orphaned postmeta
SELECT COUNT(*) FROM wp_postmeta 
LEFT JOIN wp_posts ON wp_posts.ID = wp_postmeta.post_id 
WHERE wp_posts.ID IS NULL;

自动化维护脚本

无需手动干预即可实施定期清理：

#!/bin/bash
# Database optimization script
# Schedule via cron: 0 2 * * 0 (weekly at 2 AM Sunday)

# Backup before optimization
mysqldump database_name > /backup/database_backup_$(date +%Y%m%d).sql

# MySQL optimization
mysql -e "OPTIMIZE TABLE database_name.wp_posts;"
mysql -e "OPTIMIZE TABLE database_name.wp_postmeta;"
mysql -e "OPTIMIZE TABLE database_name.wp_options;"

# Log results
echo "Database optimization completed: $(date)" >> /var/log/db-optimization.log

成本分析与投资回报

硬件升级 与 软件优化

传统方法：硬件扩展（Hetzner 价格截至 2025 年 6 月；此后 Hetzner 已调整价格并重命名多个套餐，请查看当前价格）

  • Hetzner CPX21 → CPX31：€8 → €15/月（+€84/年）
  • CPX21 → CCX23：€8 → €25/月（+€204/年）
  • 多服务器：€16+/月用于负载均衡

优化方法：软件效率

  • 实施时间：4-8 小时（一次性）
  • 持续维护：每月 1-2 小时
  • 性能提升：响应时间提速 3-5 倍
  • 成本：€0 额外托管费用

投资回报分析：

  • 盈亏平衡点：无额外托管费用；主要成本是 4-8 小时的实施时间
  • 年度节省：避免升级节省 €84-204+
  • 性能提升：相当于 2-4 倍的硬件扩展
  • 运营效益：减少支持开销，提高客户满意度

竞争优势

优化的 CloudPanel 部署以共享托管的价格提供企业级性能：

性能基准：

  • 托管 WordPress 主机：$25-50/月可获得同等性能
  • 企业托管解决方案：$100-500/月用于多网站
  • CDN 服务：$20-100/月用于全球性能优化
  • 优化的自托管：€8-15/月获得更优性能

监控与维护

自动化性能监控

实施主动监控以维持最佳性能：

#!/bin/bash
# Performance monitoring script
# Schedule via cron for regular system checks

# Check system load
LOAD=$(uptime | awk '{print $(NF-2)}' | cut -d',' -f1)
if (( $(echo "$LOAD > 2.0" | bc -l) )); then
    echo "High system load detected: $LOAD" | mail -s "Server Alert" [email protected]
fi

# Monitor MySQL performance
MYSQL_CPU=$(ps aux | grep mysql | grep -v grep | awk '{sum += $3} END {print sum}')
if (( $(echo "$MYSQL_CPU > 30" | bc -l) )); then
    echo "MySQL high CPU usage: $MYSQL_CPU%" | mail -s "Database Alert" [email protected]
fi

# Check website response times
for site in site1.com site2.com site3.com; do
    RESPONSE=$(curl -w "%{time_total}" -o /dev/null -s https://$site)
    if (( $(echo "$RESPONSE > 2.0" | bc -l) )); then
        echo "Slow response detected for $site: ${RESPONSE}s" | mail -s "Website Performance Alert" [email protected]
    fi
done

性能退化预防

通过系统化监控维持优化效果：

关键性能指标（KPI）：

  • TTFB 一致性：95% 的请求 < 500 毫秒
  • MySQL CPU 使用率：平均 < 20%
  • 可用内存：> 30% 空闲
  • PHP 进程效率：每个活跃网站 < 100 进程
  • 错误率：< 总请求的 0.1%

告警阈值：

  • 警告：性能较基线下降 25%
  • 严重：性能较基线下降 50%
  • 紧急：服务不可用或响应极慢

优化过程中的安全考量

安全实施实践

性能优化不应以牺牲安全为代价：

备份策略：

# Complete system state backup before optimization
mkdir -p /backup/pre-optimization-$(date +%Y%m%d)
cp -r /etc/mysql/ /backup/pre-optimization-$(date +%Y%m%d)/
cp -r /etc/php/ /backup/pre-optimization-$(date +%Y%m%d)/
mysqldump --all-databases > /backup/pre-optimization-$(date +%Y%m%d)/all_databases.sql

回滚程序：

# Emergency rollback script
#!/bin/bash
BACKUP_DATE="backup-date"  # Adjust to your backup date

# Restore MySQL configuration
systemctl stop mysql
cp /backup/pre-optimization-$BACKUP_DATE/mysql/* /etc/mysql/ -r
systemctl start mysql

# Restore PHP configuration  
systemctl stop php8.0-fpm
cp /backup/pre-optimization-$BACKUP_DATE/php/* /etc/php/ -r
systemctl start php8.0-fpm

echo "Rollback completed. System restored to pre-optimization state."

资源限制验证

确保优化不会产生安全漏洞：

# Monitor for resource exhaustion attacks
watch -n 5 'ps aux | grep php-fpm | wc -l'

# Set up process limits
echo "www-data soft nproc 2048" >> /etc/security/limits.conf
echo "www-data hard nproc 4096" >> /etc/security/limits.conf

超越单服务器的扩展

负载均衡策略

当单服务器优化达到极限时，考虑分布式架构：

多服务器 CloudPanel 设置：

  • 主服务器：数据库和应用处理
  • 辅助服务器：静态内容和负载分发
  • 共享存储：跨服务器的一致文件访问

我们的 Traefik 反向代理指南 为实施完善的负载均衡提供了基础，可以在多台 CloudPanel 服务器之间分发流量，同时保持 SSL 自动化和集中配置管理。

数据库集群

对于需要数据库冗余的高流量场景，请在每台专用数据库服务器上运行一个 MariaDB 节点。官方 mariadb 镜像不会读取 GALERA_* 变量，因此以下代码将 wsrep 设置作为服务器选项传入。请将示例 IP 替换为各服务器的私有地址，并且只在第一个节点首次启动时添加 --wsrep-new-cluster：

# MariaDB Galera node: one per database server, with that server's own IP
services:
  mariadb-galera:
    image: mariadb:11.4
    network_mode: host
    command:
      - --wsrep-on=ON
      - --wsrep-provider=/usr/lib/galera/libgalera_smm.so
      - --wsrep-cluster-name=cloudpanel_cluster
      - --wsrep-cluster-address=gcomm://10.0.0.11,10.0.0.12,10.0.0.13
      - --wsrep-node-address=10.0.0.11
      - --wsrep-sst-method=mariabackup
      - --wsrep-sst-auth=root:secure_password
      - --binlog-format=ROW
      - --innodb-autoinc-lock-mode=2
      # First start of the first node only: add --wsrep-new-cluster
    environment:
      - MARIADB_ROOT_PASSWORD=secure_password
    volumes:
      - mariadb_data:/var/lib/mysql

volumes:
  mariadb_data:

与现有基础设施的集成

CloudPanel API 自动化

截至 2026 年 10 月，CloudPanel 尚未提供原生 REST API 的文档；其官方自动化接口是 clpctl 命令行工具。以下示意代码假定您已自行构建或部署了该工具的 REST 封装层：

import requests
import json

# CloudPanel API endpoint
API_BASE = "https://your-cloudpanel-server:8443/api/v1"
API_KEY = "your-api-key"

# Automated website performance monitoring
def monitor_website_performance():
    headers = {"Authorization": f"Bearer {API_KEY}"}
    
    # Get website list
    websites = requests.get(f"{API_BASE}/websites", headers=headers)
    
    for site in websites.json():
        # Check performance metrics
        response_time = measure_ttfb(site['domain'])
        
        if response_time > 1.0:  # Alert threshold
            send_performance_alert(site['domain'], response_time)

持续集成流水线

将性能测试集成到部署工作流中。该作业将总响应时间保存到 RESPONSE_TIME，超过 2 秒即失败；由于 shell 的 -gt 只能比较整数，比较由 awk 完成：

# GitLab CI pipeline for performance validation
performance_test:
  stage: test
  script:
    - RESPONSE_TIME=$(curl -w "%{time_total}" -o /dev/null -s https://staging.website.com)
    - awk -v t="$RESPONSE_TIME" 'BEGIN { exit (t > 2) }'
  only:
    - main

正在构建复杂的 CloudPanel 自动化或集成流水线？clpctl CLI 支持多种管理任务，但正确的实施需要同时理解 工具和性能优化原则。我们的开发团队可以创建定制的自动化解决方案 ，在随基础设施增长扩展的同时自动维护您的性能优化。

专业基础设施支持

何时寻求专家指导

CloudPanel 优化涉及多个相互关联的系统。以下情况建议寻求专业支持：

需要专业知识的复杂场景：

  • 带负载均衡的多服务器 CloudPanel 部署
  • 需要高级缓存策略的高流量应用
  • 有特定安全要求的合规环境
  • 关键生产系统的数据库清理（风险缓解）
  • 面向专业应用的自定义 PHP-FPM 配置
  • 复杂环境中的性能退化排查

专业实施的优势：

  • 以最短停机时间部署性能优化
  • 生产实施前的全面测试
  • 为您的基础设施量身定制的监控解决方案
  • 随流量模式变化的持续优化
  • 性能相关事件的紧急支持

基础设施架构规划

超越单服务器部署需要周密的架构规划：

扩展考量：

  • 地理分布实现全球性能
  • 数据库分片策略应对大型数据集
  • 缓存层实施（Redis、Memcached）
  • CDN 集成用于静态资源交付
  • 基于流量模式的自动扩展策略

此优化基础与我们之前的基础设施指南无缝集成。如果您已实施了我们的 n8n 自托管教程，您现在可以优化底层服务器性能同时保持自动化工作流。同样，我们的 Traefik 反向代理设置 可以将优化后的 CloudPanel 流量分发到多台服务器。

快速实施指南

立即见效的优化

这些性能优化可以快速实施，并立即获得可衡量的结果：

优先级 1：MySQL 优化 （立即提升 50-70%）

# Backup and optimize MySQL configuration
cp /etc/mysql/mysql.conf.d/mysqld.cnf /etc/mysql/mysql.conf.d/mysqld.cnf.backup
# Apply buffer pool and I/O optimizations
systemctl restart mysql

优先级 2：全局 PHP 内存优化 （降低每个进程在最坏情况下的 RAM 用量）

# Reduce global memory limit
sed -i 's/memory_limit = 768M/memory_limit = 256M/' /etc/php/8.0/fpm/php.ini
systemctl restart php8.0-fpm

优先级 3：PHP-FPM 池配置 （消除冷启动延迟）

# Apply the dynamic pool settings shown above to each website pool, then test and reload
nano /etc/php/8.0/fpm/pool.d/your-website.conf
php-fpm8.0 -t
systemctl reload php8.0-fpm

预期综合效果：

  • 响应时间改善：在我们的环境中，TTFB 提速最高可达 85%
  • 资源效率：内存利用率提升 60-75%
  • CPU 优化：数据库负载减少 70-80%
  • 即时生效：所有优化在几分钟内激活

准备好转变您的 CloudPanel 性能了吗？

不要再将缓慢的网站性能视为不可避免。这些优化技术已在每月处理数百万请求的生产环境中得到验证。性能改善立竿见影且可量化——您的用户会注意到差异，而您的服务器成本将会降低。

当有专家实施可用时，为什么还要苦苦挣扎于复杂的优化？

无论您是运行单台 CloudPanel 服务器还是管理复杂的多服务器部署，专业优化都能以最小风险确保最大性能。我们已在从小型企业网站到企业级应用的各种环境中实施了这些优化。

专业性能优化服务

我们的基础设施专家实施全面的 CloudPanel 优化，提供：

  • 可衡量的性能改善，对照基线指标进行跟踪
  • 以最短停机时间实施，保持服务可用性
  • 定制的监控解决方案持续跟踪性能
  • 文档和培训支持您的团队持续维护
  • 性能相关问题的紧急支持

立即联系我们的性能优化团队 – 将您的 CloudPanel 部署从够用转变为卓越。您的网站值得拥有企业级性能，您的用户期望闪电般快速的响应时间。

总结

CloudPanel 性能优化将自托管基础设施从基本的网站托管转变为能够提供企业级用户体验的高性能平台。这些系统化优化带来立竿见影的可衡量改善，同时为可扩展增长奠定基础。

本次全面优化的关键成果：

  • 响应时间提速最高可达 85%，通过智能资源分配
  • 显著节省成本，避免不必要的硬件升级
  • 专业级可靠性，配备适当的监控和维护
  • 可扩展架构，支持业务增长而不牺牲性能

MySQL 优化、PHP-FPM 调优和系统化监控的组合创建了一个强大的托管平台，在保持完整基础设施控制的同时可与昂贵的托管服务相媲美。

此优化方法与我们全面的自托管生态系统完美契合。结合我们的 完整 Traefik 设置 实现 SSL 自动化和路由，再加上我们的 n8n 自动化平台 实现工作流管理，您现在拥有了完整、优化的自托管基础设施基础。

准备好实施这些优化了吗？ 从 MySQL 缓冲池大小设置和全局 PHP 内存限制开始，立即获得效果，然后系统地优化每个网站池以获得最大性能提升。

专业的基础设施值得专业的优化。您在系统化性能调优上的投资将通过改善的用户体验、减少的运营开销和随业务增长可持续扩展的能力带来回报。

关于 tva

tva 提供数据库系统、云环境和全球供应链的综合基础设施管理。我们系统化的方法将严格的安全协议与性能优化相结合，同时战略咨询服务实现数字能力和实物资产的精准协调——在所有业务中保持最高标准的卓越运营和合规水平。

访问 tva.sg 了解更多关于我们基础设施优化服务和全面自托管解决方案的信息。

延伸阅读

现代 Hetzner 环境中的 CloudPanel：以测量为先的性能指南

2026 年底的 Hetzner Cloud：自托管 n8n、Windmill、Twenty 和 Ollama 的套餐与价格

WooCommerce 性能优化：加载时间从 8 秒降至 0.2 秒