Error: "Failed to load application. Confirm to retry." when used through reverse proxy

  • So I recently upgraded WebApp to version and I have a weird issue that just cam to light.

    Some of our remote users access the WebApp page via a reverse proxy portal. And until the latest upgrade it worked without a bother. But now, every once in a while it pops up an error “”. The only option is to click OK, which then returns the user back to the page, so far it has been no harm no foul. But I would still like to stop that error from popping up.

    It might have something to do with the url mangling the reverse proxy uses. (i.e.):

    (Also, I found that WebMeetings also does not work through this reverse proxy )


  • Bob,

    In our case, we run both webapp and webmeetings behind a apache (centos 7) server that reroutes the requests to another VPS and it works fine.

    If this is your case and if this is helpful I could share our config?

    I am not sure it is the same case as you though.

  • Unfortunately we can’t implement a new reverse proxy or expose webapp to the internet directly, we are forced to use this reverse proxy/portal product.

  • Figured out the problem is WebMeetings. If I disable the webmeetings plugin I don’t receive the error.

    I’m assuming it is part of the webmeetings javascript to throw up this error is it can;'t contact the server and with the URL mangling that the portal uses it can’t dial home.


  • Kopano

    IIRC Webmeetings uses websockets, so your proxy needs to support these properly in order to get this working.

  • Indeed it does, that said it does work behind apache too, if that’s what you are using (at least I got it to work in centos 7).

  • Not really a fix but rather a work-around.
    I modified the config-meetings.php file so that the WebMeetings plugin will not appear if the user is coming from our DMZ portal.

     * Set to true to enable the plugin by default
     * Set to true to load the plugin on WebApp start up
    } else {

    I’m currently working with our Portal provider to see if they can support WebSockets.


Log in to reply