A seedbox with feralhosting can’t be accessed with app.plex.tv (unavailable) but is accessible remotely if I go directly to server.feralhosting.com:port.
I note the following over and over in the console and I figure this is the reason why it’s unavailable via app.plex.tv.
I’ve shown this to feral support and they say the problem isn’t on their end.
What do I do? Thanks.
Aug 23, 2019 15:37:58.459 [0x7f5547154700] Debug — WebSocket: Performing handshake from origin http://clytius.feralhosting.com:29284
Aug 23, 2019 15:37:58.459 [0x7f5547154700] Debug — Beginning read from WebSocket
Aug 23, 2019 15:37:58.688 [0x7f556e860700] Debug — Auth: authenticated user 1 as repentance
Aug 23, 2019 15:37:58.689 [0x7f5544e20700] Debug — Request: [199.249.230.12:17042 (WAN)] GET /activities (7 live) GZIP Signed-in Token (repentance)
Aug 23, 2019 15:37:58.689 [0x7f556e860700] Debug — Completed: [199.249.230.12:17042] 200 GET /activities (7 live) GZIP 0ms 429 bytes (pipelined: 2)
Aug 23, 2019 15:38:11.173 [0x7f556e571700] Debug — EventSource: Resolving 82.94.168.21 port 443
Aug 23, 2019 15:38:11.173 [0x7f556e571700] Debug — EventSource: Resolved 82.94.168.21 to 82.94.168.21
Aug 23, 2019 15:38:11.181 [0x7f556e860700] Debug — EventSource: Connected in 6 ms.
Aug 23, 2019 15:38:11.182 [0x7f556e860700] Debug — EventSource: Wrote data, reading reply.
Aug 23, 2019 15:38:11.266 [0x7f556e860700] Debug — EventSource: Read HTTP reply header.
Aug 23, 2019 15:38:11.266 [0x7f556e860700] Debug — EventSource: Failure in ParseHeader: HTTP/1.1 403 Forbidden
Server: nginx
Date: Fri, 23 Aug 2019 15:38:11 GMT
Content-Type: text/html
Content-Length: 162
Connection: close
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx</center>
</body>
</html>
(0 - Success).
Aug 23, 2019 15:38:11.275 [0x7f556e860700] Debug — EventSource: Stopping.
Aug 23, 2019 15:38:11.275 [0x7f556e860700] Debug — PubsubServerManager: Switching to next host in region: 82.94.168.25
Aug 23, 2019 15:38:11.278 [0x7f556e860700] Debug — EventSource: Stopping.
Aug 23, 2019 15:38:11.278 [0x7f556e860700] Debug — EventSource: Resolving 82.94.168.25 port 443
Aug 23, 2019 15:38:11.278 [0x7f556e571700] Debug — EventSource: Resolved 82.94.168.25 to 82.94.168.25
Aug 23, 2019 15:38:11.286 [0x7f556e571700] Debug — EventSource: Connected in 6 ms.
Aug 23, 2019 15:38:11.286 [0x7f556e571700] Debug — EventSource: Wrote data, reading reply.
Aug 23, 2019 15:38:11.366 [0x7f556e860700] Debug — EventSource: Read HTTP reply header.
Aug 23, 2019 15:38:11.366 [0x7f556e860700] Debug — EventSource: Failure in ParseHeader: HTTP/1.1 403 Forbidden
Server: nginx
Date: Fri, 23 Aug 2019 15:38:11 GMT
Content-Type: text/html
Content-Length: 162
Connection: close
Feral hosting is the ONLY provider I know for fact does not work with PMS.
Feral uses Linux Namespaces for isolation between their customers.
Plex does not use Linux Namespaces.
Plex is written to have only one active “Plex Media Server” process per system.
Feral’s implementation puts many in the same Process Table.
As such, when one PMS starts for one of their customers, everyone else gets shut down.
I have been around this many times and there is no resolution.
Thanks for the answer. It’s good to know a reason why.
But the weird thing is I had a different slot with feral in the past and plex worked just fine with app.plex.tv. Should I assume I was the only one on that server using plex?
But I don’t think this is related to one or many instances of Plex running, I mean the error is pretty clear that there’s a malformed header or maybe something required that’s missing in the connection, I don’t see how that relates to running one or many processes of anything in any server.
I think it would be helpful to get a better detail of the unauthorized response, I didn’t have this problem with previous versions of PMS so that means that there’s definitely something that changed in Plex servers (meaning, web-servers, proxies, load balancers, etc) which broke the behavior. This may be related to how PMS process runs, but so far there’s no logic connection between PMS running in multiple processes and an Nginx server returning a 403.