要让php应用在docker中支持https,核心是将ssl证书和密钥配置到nginx或apache容器中,并确保与php-fpm容器协同工作。1. 创建自签名证书,用于开发环境;2. 编写php-fpm和nginx的dockerfile;3. 配置nginx以启用https并转发php请求到php-fpm;4. 使用docker-compose编排服务并挂载证书和代码目录;5. 修改本地hosts文件解析域名到127.0.0.1。若https无法访问或出现证书错误,常见原因包括:证书路径错误、端口未暴露或被占用、nginx配置语法错误、防火墙限制、自签名证书未被信任、混合内容问题或dns解析错误。开发环境快速搭建https的要点是:使用openssl生成证书、统一certs目录、docker-compose挂载证书、nginx配置正确路径、设置hosts文件。生产环境应采用let's encrypt和certbot自动管理证书,通过独立certbot容器配合http或dns挑战方式获取证书,并配置自动续订机制,确保证书长期有效;同时注意权限控制、备份、邮件通知等安全措施。

在Docker里让PHP应用跑上HTTPS,说白了,就是要把你的SSL证书和密钥妥帖地安放在Web服务器(比如Nginx或Apache)的容器里,然后配置它监听443端口,并用这些证书来加密通信。同时,确保Web服务器和PHP-FPM容器能无缝协作,让你的PHP代码在安全的环境下被执行。

要搞定这事儿,我们通常会用到docker-compose来编排Nginx(或者Apache)和PHP-FPM这两个核心服务。核心思路是:Nginx负责接收HTTPS请求,处理SSL握手,然后将PHP相关的请求转发给PHP-FPM容器处理。
我们先准备好自签名的SSL证书,这在开发环境里特别方便,省去了申请正式证书的麻烦。在你的项目根目录下创建一个certs文件夹,然后执行:
立即学习“PHP免费学习笔记(深入)”;

mkdir -p certs openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout certs/nginx.key -out certs/nginx.crt -subj "/CN=yourdomain.local"
这里yourdomain.local可以是你本地hosts文件里指向127.0.0.1的任何域名,比如app.local。
接下来,我们需要一个Dockerfile来构建我们的PHP-FPM服务,以及一个Nginx的配置文件。

1. php/Dockerfile (假设放在项目根目录下的php文件夹里):
FROM php:8.2-fpm-alpine # 安装常用的PHP扩展,根据你的项目需求添加 RUN docker-php-ext-install pdo_mysql opcache WORKDIR /var/www/html
2. nginx/Dockerfile (假设放在项目根目录下的nginx文件夹里):
FROM nginx:alpine # 复制自定义的Nginx配置 COPY nginx.conf /etc/nginx/conf.d/default.conf # 复制证书文件,这里假设证书在项目根目录的certs文件夹 # 在docker-compose.yml中通过volume挂载更灵活,这里只是示例 # COPY ../certs/nginx.crt /etc/nginx/certs/nginx.crt # COPY ../certs/nginx.key /etc/nginx/certs/nginx.key WORKDIR /var/www/html
3. nginx/nginx.conf (Nginx的HTTPS配置):
server {
listen 80;
listen [::]:80;
server_name yourdomain.local; # 替换成你的域名
return 301 https://$host$request_uri; # 强制HTTP跳转到HTTPS
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name yourdomain.local; # 替换成你的域名
# SSL证书路径,这里会通过docker-compose的volumes挂载进来
ssl_certificate /etc/nginx/certs/nginx.crt;
ssl_certificate_key /etc/nginx/certs/nginx.key;
# 推荐的SSL配置
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";
root /var/www/html/public; # 你的应用入口目录,例如Laravel的public
index index.php index.html index.htm;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
fastcgi_pass php:9000; # php是docker-compose服务名,9000是PHP-FPM默认端口
fastcgi_index index.php;
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
# 隐藏Nginx版本信息
server_tokens off;
}4. docker-compose.yml (编排服务):
version: '3.8'
services:
nginx:
build:
context: ./nginx # Nginx的Dockerfile路径
ports:
- "80:80"
- "443:443"
volumes:
- ./src:/var/www/html # 挂载你的项目代码
- ./certs:/etc/nginx/certs # 挂载SSL证书和密钥
- ./nginx/nginx.conf:/etc/nginx/conf.d/default.conf:ro # 确保Nginx配置被正确加载
depends_on:
- php
restart: unless-stopped
php:
build:
context: ./php # PHP的Dockerfile路径
volumes:
- ./src:/var/www/html # 挂载你的项目代码
restart: unless-stopped
# 如果需要,可以暴露PHP-FPM的端口,但通常Nginx内部访问即可
# ports:
# - "9000:9000"5. src/public/index.php (一个简单的测试文件):
<?php echo "Hello from HTTPS PHP on Docker!"; phpinfo(); ?>
最后,在你的项目根目录下运行docker-compose up -d --build,然后修改你的本地hosts文件(Windows在C:\Windows\System32\drivers\etc\hosts,macOS/Linux在/etc/hosts),添加一行:
127.0.0.1 yourdomain.local
现在,访问https://yourdomain.local,你应该能看到PHP的输出,并且浏览器会提示证书不信任(因为是自签名的),但连接是加密的。
这问题问得好,每次搞SSL,总能遇到些稀奇古怪的坑。我个人觉得,最常见的无非就那么几类:
ssl_certificate和ssl_certificate_key里填的路径,是不是真的指向了容器内部的正确文件?你可能在宿主机上路径没错,但容器里挂载进去后,路径变了。检查docker-compose.yml里的volumes配置,确保证书文件确实被挂载到了Nginx容器内部nginx.conf里指定的路径。比如我上面例子里,Nginx容器内部证书路径是/etc/nginx/certs/nginx.crt,而宿主机是./certs/nginx.crt。如果路径写错了,Nginx启动时就会报错,或者直接拒绝加载SSL。docker-compose.yml里nginx服务的ports部分有"443:443",这意味着宿主机的443端口会映射到Nginx容器的443端口。如果宿主机的443端口已经被其他服务(比如IIS、Apache或者其他Nginx实例)占用了,Docker就无法绑定,容器可能启动失败。这时候你可以试试映射到其他端口,比如"8443:443",然后访问https://yourdomain.local:8443。nginx -t来检查配置文件的语法。docker-compose exec nginx nginx -t是个好习惯。hosts文件里配置了yourdomain.local,但浏览器可能缓存了旧的解析,或者你访问的根本不是你配置的那个域名。遇到问题,别慌,先看Docker容器的日志(docker-compose logs nginx),通常能找到蛛丝马迹。
在开发环境,我们的核心诉求是“快”和“简单”,不用太纠结于证书的权威性。上面解决方案里,其实已经给出了一个非常快捷的方法,核心就是自签名证书。
说白了,你不需要去申请什么Let's Encrypt,也不需要花钱买商业证书。用openssl命令自己生成一对密钥和证书文件就行。我个人通常这么干:
certs目录: 我会在我的所有Docker项目外面,或者每个项目根目录里放一个certs文件夹。openssl命令:mkdir -p certs openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout certs/dev.key -out certs/dev.crt -subj "/CN=*.localdev"
这里我用了*.localdev,这样我就可以用app1.localdev、app2.localdev等多个子域名,而只需要一个证书。当然,你也可以直接用yourdomain.local。
docker-compose.yml里挂载: 确保你的docker-compose.yml里,Nginx服务的volumes部分有类似./certs:/etc/nginx/certs的挂载,把宿主机的证书文件映射到Nginx容器内部。nginx.conf里ssl_certificate和ssl_certificate_key指向容器内部的证书路径。hosts文件配置: 最后一步,也是最容易忘的一步,就是在你的操作系统hosts文件里把yourdomain.local(或者app.localdev之类的)指向127.0.0.1。这样当你访问这个域名时,请求才会打到你的本地Docker容器上。这样一套流程下来,基本五分钟就能跑起来一个支持HTTPS的本地开发环境。虽然浏览器会提示不安全,但功能上是完全没问题的,而且也能模拟生产环境的HTTPS行为,比如处理重定向、Cookie的安全属性(Secure、HttpOnly)等。调试起来也方便,因为你知道证书问题不是生产环境那种“真的”证书问题。
生产环境可就不能像开发环境那样随心所欲了。这里我们追求的是自动化、安全和可靠性。我个人最推荐的方案是结合Let's Encrypt和Certbot,再配合Docker的编排能力。
Let's Encrypt与Certbot: Let's Encrypt提供免费的SSL/TLS证书,而Certbot是其官方推荐的客户端工具,能够自动化地获取和续订证书。Certbot支持多种Web服务器和挑战模式。
Docker中的Certbot集成策略:
独立Certbot容器: 这是我比较喜欢的方式。你可以运行一个独立的Certbot容器,它负责获取和续订证书。这个容器需要能够访问Web服务器的.well-known/acme-challenge路径(HTTP挑战),或者能够修改DNS记录(DNS挑战)。
Nginx作为反向代理和Certbot的卷共享:
version: '3.8'
services:
nginx:
image: nginx:alpine
ports:
- "80:80"
- "443:443"
volumes:
- ./src:/var/www/html
- ./nginx/nginx.conf:/etc/nginx/conf.d/default.conf:ro
- certbot-web:/var/www/certbot # 用于Certbot的HTTP挑战
- certbot-etc:/etc/letsencrypt # 证书存储
depends_on:
- php
restart: unless-stopped
php:
# ... (同上)
certbot:
image: certbot/certbot
volumes:
- certbot-web:/var/www/certbot
- certbot-etc:/etc/letsencrypt
# 命令示例,首次获取证书
# command: certonly --webroot -w /var/www/certbot --email your_email@example.com -d yourdomain.com --agree-tos --no-eff-email
# 命令示例,续订证书(通常通过cron job或docker-compose exec运行)
# command: renew --webroot -w /var/www/certbot --post-hook "docker-compose exec nginx nginx -s reload"
entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $!; done;'" # 自动续订
restart: on-failure # 如果失败就重启
volumes:
certbot-web:
certbot-etc:在Nginx的配置中,你需要为Certbot的验证路径添加一个location块:
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}首次运行Certbot命令获取证书后,Nginx配置中的ssl_certificate和ssl_certificate_key就应该指向/etc/letsencrypt/live/yourdomain.com/fullchain.pem和/etc/letsencrypt/live/yourdomain.com/privkey.pem。
自动化续订: Let's Encrypt证书有效期只有90天。所以,自动化续订是必须的。上面certbot服务的entrypoint就提供了一个简单的自动续订机制,每12小时尝试续订一次。续订成功后,通常需要重启或重新加载Nginx配置,让它加载新证书。--post-hook "docker-compose exec nginx nginx -s reload"就是干这事的。
安全考虑:
certbot-etc卷的权限设置正确,只有必要的进程才能访问私钥。certbot-etc卷中的证书和密钥,以防万一。更高级的工具: 对于更复杂的生产环境,可以考虑使用像Traefik或Caddy这样的边缘路由器/反向代理。它们内置了Let's Encrypt支持,可以自动管理证书的获取和续订,大大简化了HTTPS的配置。你只需要配置好域名,它们就能自动搞定SSL,非常省心。但如果你已经习惯了Nginx,上面的Certbot方案也足够强大和灵活。
总而言之,生产环境的SSL配置,核心在于自动化和可靠性,确保证书始终有效,并且能够自动更新,避免因为证书过期导致的服务中断。
以上就是如何用Docker配置PHP环境支持SSL PHP容器启用HTTPS访问方法的详细内容,更多请关注php中文网其它相关文章!
PHP怎么学习?PHP怎么入门?PHP在哪学?PHP怎么学才快?不用担心,这里为大家提供了PHP速学教程(入门到精通),有需要的小伙伴保存下载就能学习啦!
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号