Attempting to access the WLED configuration website pages BEHIND a PROXY does not work correctly.

[dartunder]

What happened?

I have a Raspberry PI 4 running Falcon Player - FPP. It's configured as a proxy for other pixel controllers as they are on an isolated network.

These pages have errors and don't work http://fpp.local/proxy/wled-b272dc.local/ http://fpp.local/proxy/wled-b272dc.local/settings

To Reproduce Bug

Put a wired ethernet-based WLED behind an FPP as a proxy and attempt to access the settings page.

Expected Behavior

Normal access to the device as if connected directly.

Install Method

Binary from WLED.me

What version of WLED?

0.14.0

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

No response

Anything else?

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[blazoncek]

That's your Raspberry Pi proxy problem, not WLED. WLED since 0.14.0-b3 works well with reverse proxies set up properly.

[drewbeer]

WLED should not be using absolute URLs or at least have a choice

[blazoncek]

I agree and you are welcome to implement it using limited AsyncWebServer which is at the core of WLED. Until then, current implementation is the best you can get for working behind reverse proxy.

Of course that applies to using WLED UI. You can use JSON API directly by calling http://some_ip/somepath/json/state where you can replace some_ip with the address of your proxy server and somepath with correctly set up reverse proxy mapping of WLED device. Since there are plenty of reverse proxies available I cannot provide an exact set-up of reverse proxy server.

If you want to use websockets you'll need to add correct configuration to proxy server. WLED dos not support encrypted communication.

[blazoncek]

Please try: http://fpp.local/wled-b272dc.local/

Without the proxy subpath. EDIT: You will need to configure proxy for that.

[dartunder]

Please try: http://fpp.local/wled-b272dc.local/

Without the proxy subpath. EDIT: You will need to configure proxy for that.

thanks but it doesn't work that way on a Falcon Player ( FPP )

[blazoncek]

I think I have it sorted out. Will be available in 0.15.

[blazoncek]

fabd3b8421b0b3e5881b8dd97f7cdb37d457b189

[dartunder]

@blazoncek thank you for taking the time to address this issue.

[rulkens]

I have encountered an issue that seems to be caused by a similar problem: I have a reverse proxy setup where I access WLED through another IP, with a specific port, i.e. http://192.168.1.100:5000. I can access the /settings urls, but as soon as I try to navigate to the main / url, it tries to redirect me to 4.3.2.1. Seems that needs a separate fix?

Using the new 0.14.1 build from this year.

[blazoncek]

@rulkens please provide network trace as seen from your browser (or Wireshark if possible).

[rulkens]

[blazoncek]

@rulkens it looks like you'll need to expose the host for me to verify (PM on Discord). It does seem there might be a bug when detecting where the request was destined.

bool captivePortal(AsyncWebServerRequest *request)
{
  if (ON_STA_FILTER(request)) return false; //only serve captive in AP mode
  String hostH;
  if (!request->hasHeader("Host")) return false;
  hostH = request->getHeader("Host")->value();

  if (!isIp(hostH) && hostH.indexOf("wled.me") < 0 && hostH.indexOf(cmDNS) < 0) {
    DEBUG_PRINTLN("Captive portal");
    AsyncWebServerResponse *response = request->beginResponse(302);
    response->addHeader(F("Location"), F("http://4.3.2.1"));
    request->send(response);
    return true;
  }
  return false;
}

[blazoncek]

The issue is not using WiFi but Ethernet instead. Will be fixed in next release.

[blazoncek]

Available in 0.15.0 beta 1.