Those are bad questions. The task is given, you're asking why do I have these constraints - obviously you have them because they made them. Without the constraints there's no task.
It doesn't matter why you can't fix the server, you can't fix the server. It doesn't matter why it can only handle one request at a time, it can only handle one request at a time. That information doesn't change the solution to the task. Make up whatever you please - maybe it's a third party system so you can't access the code. Now try to come up with some useful questions that actually help you solve the task instead of wasting time asking pointless questions.
No wonder people reject you if this is how you approach interviews. Maybe it would make sense to ask these kinds of questions in a real work scenario, but it does not make sense in an interview where you are given a made up task. Just accept the constraints and solve the problem. You sound like a high school student being intentionally obtuse, like you came into the interview thinking you're too good to be evaluated that way or maybe you just don't have a clue how to solve the actual problem you're given so you try to stall to avoid having to admit that you can't do it.
On the contrary, these are great questions to raise at the start and I'd absolutely rate a candidate better for asking them. Too many of my coworkers solve the wrong problem. They treat the symptoms instead of finding the root cause, and so we end up with a fragile patchwork of dirty hacks that get cargo-culted into other code bases.
That being said, the time spent on these questions should be minimal. It should go something like:
Candidate: It seems like we're solving the wrong problem. Why can't the server handle multiple simultaneous requests from a single client?
Interviewer: Its a 3rd-party server we don't control. (or even just a "because those are the artificial constraints for this puzzle" if the interviewer is feeling particularly lazy)
Candidate: Ah okay. <proceeds to work on the problem>
Sure, that's completely reasonable. But getting hung up on them for an hour is ridiculous.
I also think they're unnecessary in the first place. I wouldn't hold it against anyone in a scenario like you described but I also wouldn't expect it. Solving the task as it's posed is good enough.
I might just mention that my first instinct would be to fix the root of the problem instead of asking about it, I wouldn't expect the interviewer to have spent time world building for their made up task.
It doesn't matter why you can't fix the server, you can't fix the server. It doesn't matter why it can only handle one request at a time, it can only handle one request at a time. That information doesn't change the solution to the task. Make up whatever you please - maybe it's a third party system so you can't access the code. Now try to come up with some useful questions that actually help you solve the task instead of wasting time asking pointless questions.
No wonder people reject you if this is how you approach interviews. Maybe it would make sense to ask these kinds of questions in a real work scenario, but it does not make sense in an interview where you are given a made up task. Just accept the constraints and solve the problem. You sound like a high school student being intentionally obtuse, like you came into the interview thinking you're too good to be evaluated that way or maybe you just don't have a clue how to solve the actual problem you're given so you try to stall to avoid having to admit that you can't do it.