It's not really knowing "how far each of your higher fidelity prototypes are from the real thing," it's more about knowing enough to understand limitations and workarounds. Many times, this is less about knowing the actual language than it is understanding the basic concepts of how server-side languages work and interact with a system architecture to fetch and display information.
When it comes to server-side tech, the biggest piece that you need to understand is the toll your designs are taking on the system as a whole.
For instance, I work for a company that does software for financial advisors. Specifically, we support trading on the stock market for multiple clients at once. This can sometimes mean that we have hundreds of thousands of records being generated for each individual trade. Due to our architecture, this means that every time we need to go back and request that data set, it can take upwards of 30s before the returned results are actually displayed.
While 30s really is inexcusable in the UX world, there's nothing that I can do for that-- that initial response time has nothing to do with my designs, it's simply an architecture limitation.
What I do know is that our system will store some of that data in memory, and based on the technology we use I can do some work to transform that data without making a new call to our database and waiting another 30s for the transformed data to be displayed. Some changes, however, I can't make without making another call to our database and therefor waiting an eternity for the new data set to load.
My team uses a littany of languages and systems I have zero knowledge of. What I do know, however, is enough conceptually about how our front end works and how our server-side coding and responses work to create designs that limit calls to our database while still giving back useful results.
In short, for the server-side piece, focus on the concepts initially. If you'd like to learn a specific server-side language down the road, it'd certainly be helpful, though not strictly necessary.