So, where to start . . . and some of this may well be things that fall into the class of "it would be nice to do that, but I can't."
First, there seems to be some confusion over what you're testing. If you're testing something that needs to interact with the outside world, and you want to focus your testing on that something, you need to do one of two things: either replace the outside world with mocked servers that only return the data you want to return, or you need to control the servers the system under test is talking to. If you can't do either of those, and more to the point in this case, the server being communicated is changing as well, you aren't just testing "your" software, you're testing the system. System failures are failures that will need to be debugged.
Second, if the software under test is misbehaving in some way, and you can't figure out why, that's a problem in and of itself. Put yourself in the place of the end user; if you, as a tester, can't figure out what's causing a problem, a normal user won't be able to either. As Rsf says, you probably need more/better logging.
And, finally, you'd originally put a tag in here about test automation. The environment you describe, where you don't control a lot of the pieces, isn't a good fit for automated testing. By it's nature, you really need to control all parts of the system when doing automated testing, so you can be sure that the automated testing is seeing the behavior you intend it to test.