If you’re talking 100’s, maybe 1000’s, but not more, then I’d guess an AActor-based solution should probably be able to cope. In that case, as NegInfinity says your easiest solution would be an engine mod to fix your current issue.
As for the other approach - I’m pretty certain the bulk (if not all) of the code handling both physics and occlusion is at the level of UPrimitiveComponent. So you could I think have a single actor, containing an array of components for the projectiles. Of course, you’re still then replicating component data for every projectile, but I guess that’s considerably more lightweight than actor data.
Having said that, I just checked now and it looks like there is no component-level control of network relevancy, meaning at any time, you’d be replicating either all the projectiles or none of them. That’s not really gonna fly. Presumably you just want replication for purposes of visualizing the projectiles to each client? In that case you only want to be replicating those that are within some range of the client camera, right?
You could go super low level: have a manager that simulates the projectiles on the server, but manually tracks network relevancy and replicates a custom array of projectile position/state to individual clients (and doesn’t replicate any components), with the clients then building their own scene components from the received data. That would be getting a bit crazy though, you’d have to be sure the projectile replication was totally killing your game before wanting to do that.
Actually I suspect that physics code might be decoupled from even component, because skeletal mesh might be controlled by several rigid bodies (PhysicsAsset) and I vaguely remember seiing some kind of FSomethingPhysXRelated structure somewhere. If you search through engine code for physx references/subroutines you should find that one - all object settings, like use of CCD are stored in it.