There's a persistent confusion in the React ecosystem: Server Components are treated as a React feature, something React added. They're not. They're a framework feature that React enables — and the distinction matters more than it might seem.
What React actually provides
React provides the component model and the reconciler. That's it. React doesn't know what a "server" is. react and react-dom have no concept of server-side rendering vs client-side rendering in the component model itself.
What React does provide is a protocol — a way to serialize component trees and stream them to a client. But something has to implement that protocol. That something is your framework.
The framework does the work
Next.js implements Server Components. Remix has its own approach. A bare React app has neither.
When you write a Server Component in Next.js, you're writing something Next.js knows how to handle — not something React handles directly. The component runs on the server because Next.js runs it there. The serialization, the streaming, the hydration boundary management — that's all Next.js.
Why it matters
Because when Server Components behave in unexpected ways, you're debugging Next.js, not React. The docs you need are the Next.js docs. The source code to look at is the Next.js source code.
Treating them as a core React feature leads to misplaced mental models: expecting behavior that React would enforce consistently, being confused when different frameworks implement them differently, looking in the wrong places when something breaks.
The useful mental model
Think of React as providing vocabulary and Server Components as a sentence written in that vocabulary by your framework. The grammar rules are React's. The sentence, and what it actually does, belongs to Next.js (or whoever).