To make sure it was the original configurations, I did a new installation.
Installed lighttpd only
Did the symlink:
ln -s /etc/lighttpd/conf-available/10-proxy.conf /etc/lighttpd/conf-enabled/10-proxy.conf
Added the configuration to the /conf-available/10-proxy.conf
Restart lighttpd service
Changed the port fowarding to this new installation, and I get the same result 
But if I open locally it works: http://192.168.1.137/sonarr/
But not from outside, even without the sonarr part.
Any ideias?
if you are not able to connect even without sonarr part, issue seems to be on port forwarding. At least the default lighttpd web site should be shown. Are you able to connect to default side if you switch of 10-proxy.conf ?? Just to check if thinks are working in general.
Do you mean removing the symlink?
yes correct, and restart lighttpd. Usually you should have a plain standard installation and you should be able to reach default web site from internet.
Same results. Something is failing at the port foward then. Not sure why
you are forwarding port 80 and 443 TCP to your new device? There is nothing blocking this? I mean another firewall? There are a couple of tools on the web allowing to perform a port scan on your internet router. This should show if port 80/443 are open an reachable.
you are right.
With the fresh installation I only have port 80 open, not the 443. And with the original installation, I have both open.
So is the new machine that have port 443 closed? Or is it the router that cant connect to that port? How can I check this?
Thanks
on DietPi themselves there is nothing blocked or closed as long as you don’t install any firewall software.
Means you router is the only one controlling which port is forward from internet to your DietPi system. In a default configuration lighttpd is liten on port 80 only. So doesn’t matter if port 443 is forward. 443 comes into picture if you are going to activate HTTPS.
Open ports can be checked as follow
ss -tulpn | grep LISTEN
Pls have a look to your router to check how port forwarding is setup. There should be a single rule only, forwarding port 80 to your new DietPi system. It should not be possible to forward port 80 to the old and the new system same time.
It was because I have letsencript install on the original machine, and not on this one. This is why the port 443 was not open.
Thank you very much
Now back to the original purpose of this thread 
Now, when I use this:
$HTTP["url"] =~ "^/code($|/)" {
proxy.header = (
"map-urlpath" => ( "/code" => "" )
)
proxy.server = ( "" =>
(( "host" => "192.168.1.94", "port" => 8443 ))
)
}
I’m able to reach the login page, but once login, it does not direct me to the next page, stays in the login page.
I’ll check the documentation to see if there is any other config that I may use.
for me following was working on 10-proxy.conf. Don’t forget to have it activated again as we disabled it for testing.
$HTTP["url"] =~ "^/sonarr($|/)" {
proxy.server = ( "" =>
(( "host" => "127.0.0.1", "port" => 8989 ))
)
}
$HTTP["url"] =~ "^/radarr($|/)" {
proxy.server = ( "" =>
(( "host" => "127.0.0.1", "port" => 7878 ))
)
}
Yes, that is working for me too.
I have several endpoints working, but only 1 that I cant get to work.
The application is code-sever, and they do not have a base url path option, that is why I’m using what MichaIng suggested in the beggining of this thread.
$HTTP["url"] =~ "^/code($|/)" {
proxy.header = (
"map-urlpath" => (
"/code" => ""
)
)
proxy.server = ( "" =>
(( "host" => "192.168.1.94", "port" => 8443))
)
}
Before using the map-urlpath condition I was not able to reach the login page. Now I can, but after the login, instead of redirecting to the next page, it stays on the login page.
And at code-server logs, I do not see an invalid login attempt, so Im guessing the login works but it seems that in the response-header the location is ./ and I think it should be /code , so I think lighttpd should re-write the response somehow.
This is a nice app by the way, is visual studio code in the browser.
ah ok your are now able to connect to your new system. Unfortunately I’m not a lighttpd specialist. So my support ends at this stage
On nginx, as per code-server docs should do the trick.
server {
listen 80;
listen [::]:80;
server_name mydomain.com;
location / {
proxy_pass http://localhost:8080/;
proxy_set_header Host $host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection upgrade;
proxy_set_header Accept-Encoding gzip;
}
}
I’ve already added the “upgrade” => “enable” condition but results are the same.
$HTTP["url"] =~ "^/code($|/)" {
proxy.header = (
"map-urlpath" => ( "/code" => "" ),
"upgrade" => "enable"
)
proxy.server = ( "" =>
(( "host" => "192.168.1.94", "port" => 8443 ))
)
}
Maybe I need to try if I can change lightpd to nginx.
Are the configuration process for both similar?
from my experience nginx is somehow easier to us as revers proxy. File system structure and how to activate mods is similar.
I’ve manage to get it working
But I forgot that I have nextcloud on the original machine, so now it is not working.
Should I add this config https://github.com/MichaIng/DietPi/blob/master/.conf/dps_114/nginx.nextcloud.conf in the new machine and add the proxy_pass part? But not sure where I should put it.
I guess nextcloud is still running on the old system? It should be enough to add following on your Revers Proxy
$HTTP["url"] =~ "^/nextcloud($|/)" {
proxy.server = ( "" =>
(( "host" => "x.x.x.x", "port" => 80 ))
)
}
BTW on which system you are doing the SSL termination? It’s enough to do it on the Revers Proxy. No need to have it done on system not directly reachable from internet.
Hi, I’ve changed to nginx now
I’ve added this to nginx:
location /nextcloud/ {
proxy_pass http://192.168.1.94:80;
}
And when I open the url http://mydomain/nextcloud from home, it changes the url to http://192.168.1.94:80/nextcloud
SSL is actually on both systems, since I did not removed from old one yet.
for nginx it should looks like this if I’m not mistaken
location /nextcloud {
proxy_pass http://192.168.1.94:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Ok I got it working on a test scenario
- VM hosting Nginx + SSL (dietpi-letsencrypt)
- VM hosting Lighttpd + Nextcloud
No changes done on VM2
On VM1 I created /etc/nginx/sites-dietpi/nextcloud.conf
location /nextcloud {
rewrite ^ /nextcloud/index.php;
}
location ~ ^/nextcloud/(index.php)? {
proxy_pass http://192.168.0.14:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Port forwarding is active from Internet towards VM1 on port 80 + 443. Nextcloud is reachable from extern as well as intern on the FQDN