Regarding the bullet through paper issue...
The problem lies in the way the object is moved and the collisions are detected. If a wall is 1 unit thick but a projectile is moving at 3 units per frame then it is very likely to be seen on Frame 1 on one side of the object, then when the position for it is calculated on Frame 2 it is already on the other side of the object and never registers a collision on the wall because it literally never collided with it. The 'speed' is how many units per second something moves and movement is just a change of position so this is a fundamental problem where the two objects never collided and therefore don't register a collision.
One fix that is cheap is to make the collider longer. This can work, but is awkward to work with sometimes. It makes it so that when the situation above does occur, the collider tail is long enough to touch the object that it passed through. This can make all of your collision data unreliable because the projectile would be registering a hit from the other side of the object it passed through.
I generally fix this by Raycasting from the last position to the current position every frame.... If the raycast hits anything then I know that it went 'through' something and I just stop it there and register the hit. This works fine for objects that are traveling very fast but can still be seen... however this can eventually get costly with all the raycasting happening on top of the regular projectile calcs..
If your objects are going super fast and cannot be seen then there is no reason to spawn something physically visible. The best solution is to just raycast from the barrel, forward... This is completely reliable and best for instant hit type things like actual bullets that are obviously going to fast to be observed. You can draw a line renderer or trail for these and see the effect of the projectile and it is common practice to do that.