How should I manage Diffie-Hellman parameters on a Web Server? Is there a best practice for Diffie-Hellman parameters (p, g, and q) used on a web server?

The server is using ephemeral keys, but should the parameters be rotated on a regular basis? Is it OK for the server to keep them fixed for years (in the source code)? Or should they be generated uniquely for each site?

This server does not appear to be under NIST and FIPS, so I don't believe they need to be fixed for compliance.
I will address your question below, however I have a serious concern that I want to bring up first. I glanced at the $p$ used in ngx_ssl_dhparam, and it is not immediately obvious that it was chosen correctly.  Unless you know that whoever generated that value knew what they were doing, you should select a different value.

The security of DH depends on, among other things, the factorization of $p-1$.  If $p-1$ has a prime factor $q$ (and $g$ wasn't selected such that $g^{(p-1)/q}\equiv 1\  (\bmod p)$), then an attacker, seeing the DH public value $g^e \bmod p$, can determine $e \bmod q$ with $O(\sqrt{q})$ work.  This means that if $p-1$ has a number of moderately sized factors (which will often be true of randomly chosen primes), and $g$ wasn't carefully selected, then you'll be leaking a significant amount of information; quite potentially enough to make DH completely insecure.

In your case, we have $g=2$; this would appear to make it unlikely that $g$ was chosen to avoid small factors.  And, if $p$ were a safe prime, this would not be much of a concern (because safe primes have no small factors to $p-1$ other than $2$), however you stated (and I have not confirmed) that their specific $p$ is not a safe prime.  I do note that, with $g=2$, your group has $g^{(p-1)/2} \neq 1$, and hence you do leak at least one bit of $e$ -- if that were all you leaked, that would not be much of a concern; however it begs the question "what else is being leaked".

I haven't checked if your $p-1$ has small factors; unless you check (or you trust whoever generated it), I would strongly urge that you use a different value of $p$.  This specific value of $p$ might be secure, however I don't know that (and I suspect you don't either). When I am asked for recommendations for DH groups, I always send people to the IKE groups; those are all safe primes (and work well with $g=2$, not leaking even that one bit)

Now, to go back and answer your question: no, you shouldn't have to rotate the group parameters on a regular basis.  It turns out that solving the problem "given these $N$ DH exchanges over the same group, solve any one of them" is not actually any easier than "given this 1 DH exchange, find the shared secret".  That is, if the group is weak when you reuse it for DH, you shouldn't be using that group in the first place.

On the other hand, a 1024 bit value of $p$ is getting to be fairly small nowadays.  NFS has been used to factor a 768 bit value recently; it should not be that long before it could practically be used to solve 1024 bit DH problems (which would mean that your group could be broken, even if $p$ was chosen without any inherent weaknesses).  I would suggest you consider at least a 1536 bit $p$ (and preferably a 2048 bit value); from what we know, those should be secure for a number of years.



Update: I just double-checked; $p$ is indeed a strong prime, that is, $(p-1)/2$ is also prime.  Hence, the concerns I raised about $p-1$ having small factors do not apply; there is a 1-bit leak (because of the factor 2 of $p-1$), however there is no other leakage.

My concern about the size of $p$, and whether that would be secure long-term, still remain.  I'll leave in the comments about weaknesses that may arise with $p-1$ having small factors; even if they don't apply in this case, future readers may find it useful.