Remote Connections Stopped Working

[V1perN3st]

Hello,

I recently ran into an issue where connections to vTube Studio, using VTubeStudioJS package, from a remote computer (meaning VTS is on one system and VTubeStudioJS is on another) stopped working reliably. It works fine when used locally (with Localhost, 127.0.0.1, or the FQDN of the computer) and I can hit the WebSocket using a Web Browser WebSocket Client from the remote system as a test (this also confirms it can communicate and Firewall/Network is not an issue). Because the VTubeStudio is integrated into a Script for Firebot (a Twitch Bot), I created a Node.js script that attempts to get the connection information (statistics) from vTube Studio. It used the same WebSocket package as the script. Running it locally, it works as expected (confirming the node.js script is working). Running it remotely I can see the request hitting VTS, but no response and no prompt to allow (just like the Firebot Script).

Basically I can see vTube Studio get the request from the remote system, but it does not seem to respond (I have confirmed this with a Packet Capture). I attempted setting the Timeout from 1 second to 3 seconds in VTubeStudioJS as I had an interesting thing happen. While streaming, the bot was continuously trying to connect to vTube Studio, I streamed longer then normal and eventually the script connected to vTube Studio after almost 1000 attempts (I had Twitch Integrated Throwing System connected as well, so I am not sure how much was from that vs the remote connection). I thought extending the timeout would allow it to respond, but it did not solve the issue once VTS was restarted (it just went back to the way it was before).

At this point, I am not 100% sure if it is something with VTS, if something changed in VTS that now effects VTubeStudioJS, or what the issue could be. I know the script that VTubeStudioJS was used in was not updated, but VTS was updated from the time it was working to the time it stopped working. I figured I would start here to see if something needs to be adjusted to have VTubeStudioJS communicate remotely with the current version of VTS.

Let me know if you what information I can provide to help with this.

vTube Studio Version: 1.32.57

[Hawkbat]

That does sound like a weird issue. I know VTube Studio's WebSocket server implementation has been extremely unreliable in the past, often dropping connections or failing to connect. Nothing has changed on VTubeStudioJS's end for quite a while, so I assume it's a change in VTS.

I'm afraid I don't use VTube Studio anymore so I don't have a great way of testing this at the moment. Can you see if there's any change in behavior between VTS's beta and main release versions?

[V1perN3st]

So I just preformed a raw WebSocket Client test and I think the issue is VTS is taking too long to respond to the remote system.

For reference, here is the script:

const WebSocket = require("ws");

let ip = "<ip>";
let port = 8001;
let request = '{"apiName": "VTubeStudioPublicAPI","apiVersion": "1.0","requestID": "RawWSTest","messageType": "AuthenticationTokenRequest","data": {"pluginName": "VTube Test Control","pluginDeveloper": "Test","pluginIcon": ""}}';

// Raw WebSocket Test
const ws = new WebSocket(`ws://${ip}:${port}`);

ws.on('error', console.error);

ws.on('open', function open() {
    console.log(Date.now());
    ws.send(request);
});

ws.on('message', function message(data) {
    console.log(Date.now());
    console.log('received: %s', data);
}); 

When I run it on the remote machine, I get a UNIX date of 1759935656936 (2025-10-08 11:00:56 local). The timestamp on the return after I clicked "Deny" is 1759935663110 (2025-10-08 11:01:03 local).

$ nodejs ./vts-test2.js 
1759935656936
1759935663110
received: {"apiName":"VTubeStudioPublicAPI","apiVersion":"1.0","timestamp":1759935662926,"messageType":"APIError","requestID":"RawWSTest","data":{"errorID":50,"message":"User denied authentication request for your plugin."}}

If you account for 2 second to click the Deny (in this case) there is still a 5 second delay before the prompt on VTS. Looking at the code, it seems the default timeout is 1 second(?). I do see where I can pass an additional option for increase the timeout, but it doesn't seem to affect the timeout when waiting for a response in my testing.

While I do believe this is something that was caused on VTS's side, it is unclear if this is something intended or as the result of something. Either way, if the timeout on the response message could be increased it might solve the issue I am having.

I have noticed, that once the initial connection is made the responses are quicker (as if it was local).