Laragon 6 on Windows after upgrading to Apache 2.4.69 (VS18) + Redis 8.x + phpMyAdmin 6.0: errors and fixes

[rescenic]

If you want to upgrade to Apache 2.4.69, PHP 8.5, Redis 8, phpMyAdmin 6.0, here is my tips:

Laragon 6 on Windows after upgrading to Apache 2.4.69 (VS18) + Redis 8.x + phpMyAdmin 6.0: errors and fixes

Environment: Laragon Full 6.0 220916 (installed on D:\laragon, not C:), httpd-2.4.69-win64-VS18, PHP 8.5.11 (VS17 build, see #10), redis-x64-8.10.2, phpMyAdmin 6.0 (snapshot), Windows 11.

Summary

#	Symptom	Cause	Fix
1	Apache won't start: Invalid command 'SSLEngine' (AH00526)	ssl_module commented out in the new httpd.conf	Uncomment LoadModule lines
2	Apache won't start: Invalid command 'RewriteEngine'	rewrite_module / proxy_* modules commented out	Uncomment LoadModule lines
3	Menu → Error log / Access log: "No file!"	New config logs to error_log / access_log (underscore)	Rename in httpd.conf
4	openssl.exe - Entry Point Not Found (SSL_CTX_set1_server_cert_type) when adding the certificate	openssl.exe / libssl DLL mismatch	Use a self-contained OpenSSL build
5	Redis won't start: can't open config file '/cygdrive/c/D:\laragon\...'	Wrong path conversion for Redis MSYS2 builds	Start Redis from the Procfile
6	Terminal PATH points to old PHP/Apache/Redis/MySQL	bin\laragon\laragon.cmd is stale	Update by hand
7	etc\apache2\fcgid.conf mentions an old PHP	Leftover, not included by default	Update paths if you use it
8	localhost/phpmyadmin6 doesn't work	Alias used /phpmyadmin and the wrong web root	Fix the alias
9	phpMyAdmin 6: Unable to write in the cache directory (...\app\cache\twig/21)	Folders with a custom icon are read-only	Clear the read-only flag
10	Laragon warns the PHP "VS" number differs from Apache	PHP build is VS17, Apache is VS18	Rename the PHP folder (workaround)

1 and 2: "Invalid command ... defined by a module not included in the server configuration"

AH00526: Syntax error on line 41 of D:/laragon/etc/apache2/sites-enabled/00-default.conf:
Invalid command 'SSLEngine', perhaps misspelled or defined by a module not included in the server configuration

AH00526: Syntax error on line 24 of D:/laragon/etc/apache2/sites-enabled/auto.<site>.conf:
Invalid command 'RewriteEngine', ...

Cause: a new Apache folder ships with a fresh stock conf/httpd.conf in which almost every optional module is commented out. Laragon patches in ServerRoot and its own Include lines (sites-enabled, mod_php.conf, ...) but doesn't carry over modules you enabled in the previous Apache's httpd.conf. You fix one error and hit the next.

Fix: in ...\httpd-2.4.69-win64-VS18\conf\httpd.conf, remove the # from the modules your vhosts use:

LoadModule ssl_module modules/mod_ssl.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so   # SSLSessionCache shmcb:
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/mod_proxy.so                    # reverse proxy vhosts
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so  # ws:// proxying

Add expires_module / deflate_module if your .htaccess files use them. The LoadModule lines must come before the sites-enabled include, which is at the end of Laragon's patched file. Back up httpd.conf, run httpd -t, then restart Apache.

3: "No file!" for error.log / access.log

The stock 2.4.69 config has ErrorLog "logs/error_log" and CustomLog "logs/access_log" common. Laragon's menu opens logs\error.log and logs\access.log. Change them in httpd.conf:

ErrorLog "logs/error.log"
CustomLog "logs/access.log" common

Restart Apache. The files are created in ...\httpd-2.4.69-win64-VS18\logs\.

4: openssl.exe - Entry Point Not Found (SSL_CTX_set1_server_cert_type)

openssl.exe - Entry Point Not Found
The procedure entry point SSL_CTX_set1_server_cert_type could not be located in the dynamic link library ...\apache\httpd-...\bin\openssl.exe

It appears when Laragon runs openssl.exe (Apache → SSL → Add laragon.crt to Trust Store). The same message is reported in leokhoa/laragon#1170 with Apache 2.4.63, where switching Apache version fixed it.

Cause (my interpretation, not confirmed by anyone): SSL_CTX_set1_server_cert_type exists only in OpenSSL 3.2 and newer, so an openssl.exe newer than 3.2 is loading an older libssl-3-x64.dll that lacks the function. On my machine, the libssl-3-x64.dll files of Apache 2.4.69 (3.5.8), MySQL (3.5.7) and Git (3.5.7) contain the function, but the one in Apache 2.4.66 (3.0.21) doesn't. Windows resolves DLLs by name, so a mixed or older copy found on the PATH or in the folder can be loaded.

What fixed it for me: I copied openssl.exe and its matching libssl-4-x64.dll, libcrypto-4-x64.dll, openssl.cfg and p_ossltest.dll from a Scoop OpenSSL install (scoop install openssl, OpenSSL 4.0.3) into the Apache bin folder. This matches the workaround a user reported in the same discussion (replacing openssl.exe and DLLs with ones from a regular Windows OpenSSL install).

Apache itself still uses its own OpenSSL 3.5.8 (libssl-3-x64.dll, which mod_ssl loads and which the Server: ... OpenSSL/3.5.8 banner shows), while the CLI openssl.exe is 4.0.3. They use different DLL names, so they don't conflict. Apache Lounge says it stays on OpenSSL 3 for httpd for now (thread). Redo the copy after upgrading Apache if the error returns.

5: Redis (6.2.24 / 7.4.11 / 8.10.2) won't start from Laragon

Service Redis can not start. Reason:
# Fatal error, can't open config file
'/cygdrive/c/D:\laragon\bin\redis\redis-x64-8.10.2\red...': No such file or directory

These Redis builds are MSYS2/Cygwin builds (they ship msys-2.0.dll) and expect the config path in Cygwin style, e.g. /cygdrive/d/laragon/... (see the redis-windows README). Laragon does convert the path, but the result /cygdrive/c/D:\... is wrong. My guess is that it assumes C:\laragon, so installs on another drive break (unverified). I found no config or template controlling this; laragon.ini has only [redis] Version=.

Manual start works:

& "D:\laragon\bin\redis\redis-x64-8.10.2\redis-server.exe" "/cygdrive/d/laragon/bin/redis/redis-x64-8.10.2/redis.conf"

Workaround: untick Redis in Preferences → Services & Ports, then add a line to usr\Procfile (add autorun after Redis: to start it with Laragon):

Redis: wt -w 0 nt --title Redis -d "D:\laragon\bin\redis\redis-x64-8.10.2" "D:\laragon\bin\redis\redis-x64-8.10.2\redis-server.exe" /cygdrive/d/laragon/bin/redis/redis-x64-8.10.2/redis.conf

That opens a Windows Terminal tab. For a plain console instead, use the exe directly with pwd=D:\laragon\bin\redis\redis-x64-8.10.2. Laragon doesn't stop a process started via wt.

6: bin\laragon\laragon.cmd has old versions

It sets PATH and OPENSSL_CONF for Laragon's terminal. Mine still listed Apache 2.4.66, PHP 8.5.10, Redis 8.8.0 and MySQL 9.7.0, some of which no longer existed. It isn't used to start services (versions come from usr\laragon.ini), but php, redis-cli and mysql in the terminal could resolve to missing folders. I updated the four version strings by hand. Also check your Windows PATH for an old ...\httpd-2.4.66-win64-VS17\bin entry.

7: etc\apache2\fcgid.conf

It pointed to PHP 8.4.5 and 7.4.33 with C:/laragon paths and had a typo in <Files ~ "\.php$>">. It isn't included by default (the active file is mod_php.conf), so it only matters if you switch to fcgid. I fixed the paths and the quote by hand.

8: localhost/phpmyadmin6 not found

My etc\apache2\alias\phpmyadmin6.conf had Alias /phpmyadmin "…/phpMyAdmin-6.0/", the same name as the old phpMyAdmin alias, so /phpmyadmin6 didn't exist and /phpmyadmin kept opening the old one. phpMyAdmin 6.0 also serves its pages from a public\ subfolder, with app, src, vendor and config.inc.php next to it. Fix:

Alias /phpmyadmin6 "D:/laragon/etc/apps/phpMyAdmin-6.0/public/"
<Directory "D:/laragon/etc/apps/phpMyAdmin-6.0/public/">

9: Twig cache error in phpMyAdmin 6

Twig\Error\RuntimeError: ... ("Unable to write in the cache directory (...\phpMyAdmin-6.0\app\cache\twig/21).") in "home/index.twig"

I had set custom folder icons, and Windows sets the read-only attribute on such folders (needed for their desktop.ini). PHP's is_writable() returns false for read-only directories on Windows, so Twig couldn't rewrite a stale cached template. 141 of 142 folders under app\cache were read-only. Fix (keeps the icons by using the system attribute):

Get-ChildItem "D:\laragon\etc\apps\phpMyAdmin-6.0\app\cache" -Recurse -Directory | ForEach-Object { $_.Attributes = ($_.Attributes -band (-bnot [IO.FileAttributes]::ReadOnly)) -bor [IO.FileAttributes]::System }

Or simply attrib -r "…\app\cache\*" /s /d. The same applies to any PHP app that writes into a folder with a custom icon (Laravel storage, WordPress uploads, ...).

10: Laragon warns that the PHP "VS" number differs from Apache

Laragon shows an alert when the VS number in the PHP folder name differs from the Apache folder name (e.g. Apache ...-VS18 with PHP ...-VS17-x64-TS). The Visual C++ 2015 to 2022 and newer toolsets all use the same runtime (vcruntime140.dll), so a VS17 PHP works with a VS18 Apache, and the alert is only about the name.

I avoided the alert by renaming the PHP folder from php-8.5.11-Win32-VS17-x64-TS to php-8.5.11-Win32-VS18-x64-TS. php -i still reports the real build:

Compiler => Visual C++ 2022
PHP Extension Build => API20250925,TS,VS17

Laragon then writes etc\apache2\mod_php.conf with the renamed path:

LoadModule php_module "D:/laragon/bin/php/php-8.5.11-Win32-VS18-x64-TS/php8apache2_4.dll"
PHPIniDir "D:/laragon/bin/php/php-8.5.11-Win32-VS18-x64-TS"

Notes:

• mod_php needs the Thread Safe (TS) build.
• PHP extensions (.dll) must still match the real build, VS17, not the folder name.
• The VS18 Apache needs the latest Visual C++ Redistributable (Apache Lounge asks for 14.51 x64).
• Renaming a folder like this is a workaround of my own, not something Laragon documents. Use it at your own risk.

[rescenic]

"Oops! Your system prevents changing hosts file" can be caused by a read-only vhost config, not the hosts file

Environment: Laragon Full 6.0 (220916), Windows 11, Apache 2.4 + Nginx, Auto virtual hosts enabled

Symptom

On every start or reload, Laragon showed this warning and turned off "Auto virtual hosts":

Oops! Your system prevents changing hosts file. Please check your Antivirus or Permissions in Security tab or check if the file is Read-only

The dialog itself said Read-only: No and Security > Write: Yes. In fact, the hosts file had no problem:

• Its ACL gave my account Full control, and it had no read-only attribute
• It was plain ASCII with no BOM, and the #laragon magic! block was intact
• Microsoft Defender (including Controlled Folder Access) had logged no block events

Diagnosis

Process Monitor with a filter on ...\drivers\etc\hosts only showed laragon.exe reading hosts. It never opened the file for writing. A capture without filters while reloading Laragon showed the real failure:

laragon.exe  CreateFile  D:\laragon\etc\nginx\sites-enabled\auto.myapp.test.conf
             ACCESS DENIED   (Generic Read/Write, Disposition: OverwriteIf)

Root cause

With Auto virtual hosts on, Laragon regenerates every auto.*.conf in etc/apache2/sites-enabled and etc/nginx/sites-enabled before it updates hosts. I had customized one of those files into a reverse proxy and set it to read-only so Laragon wouldn't overwrite it. The overwrite then fails, the whole routine stops, and Laragon reports it as a hosts-file problem.

One side effect: only the nginx file was read-only, so Laragon quietly reset the Apache auto.myapp.test.conf to the stock DocumentRoot vhost. That serves the project folder as static files (including .env).

Tip: if you see this warning while hosts permissions look fine, check sites-enabled for read-only auto.*.conf files:

Get-ChildItem C:\laragon\etc\*\sites-enabled -Filter 'auto.*' | ? IsReadOnly

Fix: use Laragon's own mechanism, not read-only

Laragon's generated nginx file ends with:

This file is auto-generated. If you want Laragon to respect your changes, just remove the [auto.] prefix

So:

1. Rename auto.myapp.test.conf to myapp.test.conf in both etc/apache2/sites-enabled and etc/nginx/sites-enabled.
2. Clear the read-only flag.
3. Reload Laragon.

Laragon then leaves myapp.test.conf alone, doesn't create a new auto.myapp.test.conf for that host, and still writes the hosts entry.

---

Recommended way to reverse proxy (Node, SvelteKit, Next.js, etc.) in Laragon

1. Keep the folder in www/ (e.g. www/myapp). Laragon builds hostnames from folder names, so the myapp.test hosts entry keeps getting created automatically.
2. Write the config as myapp.test.conf, without the auto. prefix, for both servers. Never edit or lock auto.*.conf.
3. Don't use DocumentRoot or root for a Node app. Proxy everything to the app's port, otherwise the source tree and .env are served as static files.
4. Enable the Apache proxy modules in bin/apache/<version>/conf/httpd.conf: mod_proxy, mod_proxy_http, mod_proxy_wstunnel (WebSockets), mod_headers, mod_rewrite. ⚠️ Each Apache version has its own httpd.conf, so check these again after switching Apache versions.
5. Forward the original scheme and host (X-Forwarded-Proto, Host) so frameworks generate https:// URLs and redirects.
6. Run the app under a process manager (pm2, etc.). Apache or nginx only forwards traffic to it.

Apache: etc/apache2/sites-enabled/myapp.test.conf

define SITE "myapp.test"
define UPSTREAM "127.0.0.1:3000"

<VirtualHost *:80>
    ServerName ${SITE}
    ServerAlias *.${SITE}
    RewriteEngine On
    RewriteRule ^/?(.*) https://${SITE}/$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName ${SITE}
    ServerAlias *.${SITE}

    SSLEngine on
    SSLCertificateFile      C:/laragon/etc/ssl/laragon.crt
    SSLCertificateKeyFile   C:/laragon/etc/ssl/laragon.key

    ProxyPreserveHost On
    ProxyRequests Off
    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"

    # WebSocket path must come before the catch-all
    ProxyPass        /ws ws://${UPSTREAM}/ws
    ProxyPassReverse /ws ws://${UPSTREAM}/ws

    ProxyPass        / http://${UPSTREAM}/
    ProxyPassReverse / http://${UPSTREAM}/
    ProxyTimeout 300

    ErrorLog  "logs/myapp.test-error.log"
    CustomLog "logs/myapp.test-access.log" combined
</VirtualHost>

Nginx: etc/nginx/sites-enabled/myapp.test.conf

map $http_upgrade $connection_upgrade_myapp {
    default upgrade;
    ''      close;
}

upstream myapp_app {
    server 127.0.0.1:3000;
    keepalive 32;
}

server {
    listen 80;                      # use your Laragon nginx port
    server_name myapp.test *.myapp.test;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name myapp.test *.myapp.test;

    ssl_certificate     "C:/laragon/etc/ssl/laragon.crt";
    ssl_certificate_key "C:/laragon/etc/ssl/laragon.key";
    client_max_body_size 32m;

    location / {
        proxy_pass http://myapp_app;
        proxy_http_version 1.1;
        proxy_set_header Upgrade           $http_upgrade;
        proxy_set_header Connection        $connection_upgrade_myapp;
        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 https;
        proxy_read_timeout 300s;
    }
}

If you run Apache and nginx side by side, Laragon moves nginx off the standard ports (e.g. 81/8443). Use those ports in listen, and append the port to the redirect (https://$host:8443$request_uri).

Feature request

It would help if Laragon:

• reported the actual file that failed (here, a vhost config) instead of always blaming the hosts file, and
• skipped read-only auto.*.conf files with a warning instead of stopping the whole auto-virtual-hosts run.